Simplify Valid Application Versions

RESOLVED WONTFIX

Status

P4
enhancement
RESOLVED WONTFIX
9 years ago
3 years ago

People

(Reporter: davemgarrett, Assigned: jorgev)

Tracking

unspecified
Future
Dependency tree / graph

Details

(URL)

(Reporter)

Description

9 years ago
It seems that weekly someone files a bug asking for a version to be added to AMO these days. The list itself is now wildly unwieldy.

I suggest a simplification to make everyone's lives easier:

1) Trim down the list of what can be selected when managing a version in the developer control panel to just major versions people may have a need to bump to.

2) Allow any specific versions to be used in install.rdf so long as they are under the maximum allowed version and over the minimum allowed version.

This way quick bumps can be set using a simple list of what we want people to bump to, yet if some extension needs to set a min version to some old minor release to avoid some specific bug they can do that too.

Simplified Firefox lists for version editing:
valid min [0.3, 1.0, 1.5, 2.0, 3.0, 3.5, 3.6]
valid max [0.7+, 1.0+, 1.5.0.*, 2.0.0.*, 3.0.*, 3.5.*, 3.6.*, 3.7a1pre]
(also add to the list whatever is in install.rdf, if it's not there)

Less mess, less fuss. People still couldn't set/bump a max version too far ahead of time, the controls steer them towards the bumps we want, and finer grained control exists for those who need it and without AMO admin requests.
-> jorge for ideas/confirmation/etc.  I'm in support of anything that simplifies life. :)
Assignee: nobody → jorge
Priority: -- → P4
Target Milestone: --- → Future
(Assignee)

Comment 2

9 years ago
I like the idea of simplifying the versions drop down to only show the most relevant version groups. Most authors shouldn't be setting version ranges with specific versions anyway.

However, I'm not sure if there could be problems caused by allowing authors to have, for example, a max version of 3.6.X, where X can be anything they want. This might lead to problems.

I'm also wondering how much this would make a difference in the problem it intends to solve. We would still need to be constantly adding versions in the bleeding edge branches, and that's where most current requests come from anyway, as far as I know.
(Reporter)

Comment 3

9 years ago
There were four different requests for in-between versions recently, which is why I think there's evidence that allowing arbitrary versions in install.rdf is apparently needed.
bug 529811 - Firefox 3.0.11
bug 534289 - Firefox 3.0.12
bug 531068 - Firefox 3.6b2
bug 533948 - SeaMonkey 2.0.1

(In reply to comment #2)
> However, I'm not sure if there could be problems caused by allowing authors to
> have, for example, a max version of 3.6.X, where X can be anything they want.
> This might lead to problems.

How so? I can't think of anything other than the possibility that a developer sets it to high, which is easily fixable if they do. It is their add-on so to some extent it is their responsibility to know what the actual minimum supported version is and set it as such.

> I'm also wondering how much this would make a difference in the problem it
> intends to solve. We would still need to be constantly adding versions in the
> bleeding edge branches, and that's where most current requests come from
> anyway, as far as I know.

If we wanted to, we could automate the bleeding-edge versions and grab them directly out of the branches themselves. Not sure if it's really worth the effort, though.
(Reporter)

Comment 4

9 years ago
(In reply to comment #3)
> How so? I can't think of anything other than the possibility that a developer
> sets it to high, which is easily fixable if they do. It is their add-on so to
> some extent it is their responsibility to know what the actual minimum
> supported version is and set it as such.

typo: high->low; minimum->maximum

Though, I'm primary talking about min versions here. Generally speaking, the max should be only a latest branch pre or a dot star. We could probably enforce that if you're concerned about misuse. The min is the main thing I'd like to be more flexible.
I was going to file a request for Thunderbird 3.0.1 when I bumped into this bug.

Are there any reasons against adding an "other" field in the drop-down menu, with a textbox for specifying a custom version string? Or at least changing the tags from the current <option value="288">3.0</option> format to use something like <option value="3.0">3.0</option> so that power users can override the drop-down? (With some sanity check on the server side, of course.)

Also, should we still file separate bugs for adding new versions until this is fixed, or is there a better way for that?
(Reporter)

Comment 6

9 years ago
There's probably nothing wrong with having a drop-down of the normal values plus an "other" entry. It would just clutter things up a bit, which is why I suggested simply allowing the "other" via install.rdf.

(In reply to comment #5)
> Also, should we still file separate bugs for adding new versions until this is
> fixed, or is there a better way for that?

Yes, that would probably be best. If you have a specific need for another minor release version, file an AMO->admin bug for it (preferably referencing the bug fixed in that version that's the source of the need).
(Reporter)

Updated

9 years ago
Depends on: 549417
(Reporter)

Updated

8 years ago
Depends on: 639344
Thanks for filing this.  In an effort to not drown in existing reports we're aggressively closing old enhancements and bugs to get the buglist to a reasonable level so we can scope and process bug sprints in an effective manner.

Patches for this bug are still welcome.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.