User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8) Gecko/20051202 Firefox/1.5 Build Identifier: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8) Gecko/20051202 Firefox/1.5 The only version of Flock that AMO will accept for extensions' min/maxAppVersions is 1.0+ (according to the list at https://addons.mozilla.org/faq.php). However, upon submitting such an extension, AMO automatically rejects it because "minVersion (MinAppVer) values may only contain values 0-9 and '.' because they have to be an absolute version. minVersions like 1.0+ or 1.5.0.* are not allowed." So, it would seem that it's not possible to submit any extension that happens to support Flock. Please note that this is any extension that happens to support Flock - not merely Flock-specific extensions. So extension authors essentially have a choice between removing Flock support or not updating their extensions at all. Incidentally, extensions with a Flock minAppVersion of 1.0+ have been acceptable in the past (and, similarly, Sunbird minAppVersion 0.2+). What is the reasoning behing minAppVersion suddenly needing to be "an absolute version"? Reproducible: Always Steps to Reproduce: 1.Make an extension supporting Flock. 2.Submit it. 3.There is no step 3. Actual Results: The extension is automatically rejected by AMO. Expected Results: The extension should be accepted by AMO.

There was quite a bit of discussion regarding 1.5.0.* as a minVersion because it was being used for an extension, and people began to ask why the client wouldn't let them install the extension in question. The problem when we use 'non-absolute' versions for minVer is that something saying "everything above this version" is flawed for a floor -- because it does not let the range of acceptable versions include that floor. For example, 1.5.0.* is < 1.5, so 1.5 would not let a user install an extension with a minVer of 1.5.0.*. So the solution was to not allow non-numeric characters as a part of the version string, something that fixes the 1.5.0.* problem, but does create complications for versions like 1.0+ that relatively absolute. A possible solution would have been substituting the C++ vercomp algorithm, but now with versions like 1.5.0.* that were requested by Mozilla staff, even that would not solve our issues. So -- I'm sort of at a crossroads as far as a solution for this versioning nightmare. Do you guys have suggestions on how we should handle this? Make 1.0+ --> 1.0 or just allow + and make an exception for 1.0+? Or - we could just let people submit Flock addons outside of UMO and not have Flock as a registered application (see bug 290642). That is also a possibility. Any thoughts/input?

(In reply to comment #1) > For example, 1.5.0.* is < 1.5, so 1.5 would not let a user install an extension Blah - 1.5.0.* > 1.5... typo.

(In reply to comment #1) >Do you guys have suggestions on how we should handle this? Yes: Use version numbers. Just numbers. Dots too, sure. But none of this "+" and "*" and "a1" and "b2" nonsense. And make them monotonically increasing. None of this "1.5 is less than 1.5.0.1" nonsense.

Flock is on the list. Don't we have a bug open about minVer/maxVer?

I already brought this up a long time ago and I've advocated this since getting involved with this project. That was shot-down by a lot of people who disagree and believe we should use the alpha/beta/rc indicators... :\ Arguably there already is a standard, and that standard is used by Gecko... which is the C++ algorithm I mentioned before. See bug 304857 for more of the discussion...

Okay, then here's an alternate suggestion: Change AMO's auto-reject functionality such that it rejects illegally formed min/maxAppVersion strings, instead of any that don't happen to be on a certain list. Extension developers shouldn't have to fight with AMO.

Looks like that is the solution. *** This bug has been marked as a duplicate of 290642 ***