Closed
Bug 403797
Opened 17 years ago
Closed 15 years ago
support for pre-release updates
Categories
(addons.mozilla.org Graveyard :: Developer Pages, defect)
addons.mozilla.org Graveyard
Developer Pages
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 375359
People
(Reporter: Gijs, Unassigned)
Details
STR: 1. Add add-on to AMO, not pre-release, get it to appear in public. 2. Add update to AMO, set pre-release flag because it is a beta of a fancy new version. You don't want everyone to be updated, just want it out there so people can test it. AR: Update gets auto-nominated for public ER: Update stays where it is, because it has the pre-release flag set, or possibly that the author gets asked whether they want to push the update or not.
Updated•16 years ago
|
Target Milestone: --- → 3.5
Comment 1•16 years ago
|
||
I'm actually confused as to what the pre-release flag is specifically for. It appears to apply to the add-on as a whole instead of the different versions of that add-on. Tagging an add-on, that already has publicly released versions, as pre-release doesn't really make any sense in that context. It would probably be better if the pre-release flag was independently applied to versions of an add-on instead of the add-on itself. That way a new version could be tagged as pre-release at upload time without effecting existing versions.
Comment 2•16 years ago
|
||
Add-ons that are flagged as pre-release cannot be nominated for public in AMO 3.5.
Assignee: nobody → fligtar
Updated•16 years ago
|
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Comment 3•16 years ago
|
||
(In reply to comment #2) > Add-ons that are flagged as pre-release cannot be nominated for public in AMO > 3.5. Fligtar: I'm confused by your sentence. Do you mean add-on *updates* that are flagged as pre-release? Because that is what the bug was about originally, assuming I'm reading it all correctly. Ciao!
Comment 4•16 years ago
|
||
I am also still confused. What happens if an author sets the pre-release flag for an add-on that has already been nominated for public and accepted?
Comment 5•16 years ago
|
||
Sorry, I misinterpreted this bug. The pre-release flag is set for the add-on, not a specific version or file. This is made more obvious in the 3.5 revamp, but has always been the case. An add-on that is marked as pre-release cannot be nominated for public. I'm pretty sure the ability to have beta/development versions of extensions that are not public is filed as another bug that I can't find at the moment.
Comment 6•16 years ago
|
||
(In reply to comment #5) > I'm pretty sure the ability to have beta/development versions of extensions > that are not public is filed as another bug that I can't find at the moment. Please leave this one open until we find that other bug to mark this as a duplicate. Ciao!
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Updated•16 years ago
|
Assignee: fligtar → nobody
No longer blocks: 435601
Status: REOPENED → NEW
Summary: pre-release updates should not be pushed to public by default → support for pre-release updates
Target Milestone: 3.5 → ---
Updated•15 years ago
|
Status: NEW → RESOLVED
Closed: 16 years ago → 15 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Updated•8 years ago
|
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•