315315 - Name nightlies so they sort after 0.3a1 by version comparator

Status: RESOLVED FIXED

(Calendar :: Sunbird Only, defect)

Description

[gekacheka]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051025 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051025 Firefox/1.5

The version number 0.3a1+ sorts BEFORE 0.3a1, which sorts BEFORE 0.2+ (== 0.3pre).  That causes problems for extensions, because either
a. with minVersion "0.2+" and maxVersion "0.3a1+", or 
b. with minVersion "0.3a1" and maxVersion "0.3a1+",
produces an extension that CANNOT be installed in ANY version, because minVersion > maxVersion.  For details, see bug 315242.

Bug 315242 was filed, then recategorized as a bug in extension manager version comparator, but the change was refused.  (I guess '+' versions are deprecated, so they don't want to extend support for it?)

So the version number used by nightly builds needs to change.





Reproducible: Always

Steps to Reproduce:
see bug 315242



bug 315242 comment 0 suggested 0.3a2-
bug 315242 comment 3 suggested 0.3a1.+    ("if you must" have '+')

Comment 1

[gekacheka]

Attachment: patch 0.3a1+ to 0.3a1.+ (untested)

(patch -l -p 2 -i file.patch)

Patches files mentioned in bonsai as changed for version number.
If 0.3a1.+ is not desired, replace all 0.3a1.+ with something else that also sorts after 0.3a1 (and before 0.3a2).

If alternate is considered, can test it with
var vc =
Components.classes["@mozilla.org/xpcom/version-comparator;1"].getService(Components.interfaces.nsIVersionComparator);
vc.compare("0.3a1","0.3a1.+")

Comment 2

[Michiel van Leeuwen (email: mvl+moz@)]

I think there is a way to have different version numbers for the extension manager and the rest (a pref maybe)
I guess that would be a better solution, so we don't have to change everything else.

Comment 3

[gekacheka]

(In reply to comment #2)
> I think there is a way to have different version numbers for the extension
> manager and the rest (a pref maybe)

Maybe you're thinking of app.extensions.version which bug 304476 reports has been removed from trunk and 1.8 branch.

> I guess that would be a better solution, so we don't have to change everything
> else.

Could you clarify "better solution" and "change everything else"?

The version number used by the extension manager should be the same as the one that appears in the userAgent string in help | about  so that people know what version number to use in their extensions.

Having different version numbers in different places is likely to lead to confusion.

Only the version format used for nightlies needs to change, so the change shouldn't affect normal users.

Comment 4

[Stefan Sitter [:ssitter]]

So maybe an solution as in Firefox 1.5 betas would be appropriate. The 'name' was hard coded to 'Firefox 1.5 Beta' (Sunbird 0.3a1+ in our case), but the internal version number for Ext. Manager and in UA was 1.4.

Comment 5

[Michiel van Leeuwen (email: mvl+moz@)]

Comment on attachment 202034 [details] [diff] [review]
patch 0.3a1+ to 0.3a1.+ (untested)

After discussing this with dmose on irc, we decided that 0.3a2pre would be a better version number.
0.3a1.+ just looks weird.

Comment 6

[Michiel van Leeuwen (email: mvl+moz@)]

actually, 0.3a2pre isn't a nightly, but a prerelease...
other ideas: 
0.3a2.0+
0.3a.1+
0.3.1+
but all of them have problems. We still don't know the best version number scheme.

Comment 7

[Stefan Sitter [:ssitter]]

According to http://developer.mozilla.org/en/docs/Toolkit_version_format#Version_format the plus sign is only handled to keep backwards compatibility with the Firefox 1.0.x version format.

Currently neither Thunderbird nor Firefox use '+' for their trunk version. I think for future version this '+' should be removed for Sunbird too.

For example I could imagine something like that (in the remote future):
0.3     --> finale release
0.4a1   --> trunk builds after 0.3
0.4a2   --> an alpha release
0.4a3   --> trunk builds after 0.4a2
...
0.4pre1 --> beta release
0.4pre2 --> trunk builds after 0.4pre1
...
0.4     --> finale release

Another question would be what version number scheme is supported by AMO.

Comment 8

[gekacheka]

AMO: bug 313605 comment 18 indicates addons.mozilla.org plans to soon convert to use the same version comparison code.  It says 0.3a1 is currently a problem because they use int.int.int.char for storage but that will be changed.

Format: The 0.3a1 (nightly), 0.3a2 (release), 0.3a3 (nightly), 0.3a4 (release) format provides no explicit hint that there may be differences between different nightly installs numbered a1, a3, etc., while installs numbered a2, a4, etc. are consistent releases.

Comment 9

[Michael Morgan [:morgamic]]

Would it be possible to use some versions in addons.mozilla.org to represent 0.3a1 properly?  At the moment we won't have time to do the switch to C++ (especially with versions like 1.5.0.* in there that make it very hard to do any sort of comparison).

It might be best to choose an arbitrary version for AMO that can be used internally.  You can see some examples of what was done with other products at:
https://addons.mozilla.org/faq.php (see app version section down the page)

Comment 10

[Stefan Sitter [:ssitter]]

In Bug 322591 Comment #4 Mostafa Hosseini suggested to change the version format for the calendar extension to something like "0.3.a1.yyyymmdd".

I did a quick test how nsIVersionComparator handles this things:
    "0.3a1" < "0.3.a1+" < "0.3.a1" < "0.3.a2" < "0.3.0"

So from this point of view it would work for Sunbird too. But two questions remain:

- How to handle nightlies after a release (e.g. after 0.3.a2)?

- Does addons.mozilla.org can handle / allows version numbers like 0.3.a2?

Comment 11

[Martin Schröder [:mschroeder]]

*** Bug 322508 has been marked as a duplicate of this bug. ***

Comment 12

[Matthew (lilmatt) Willis]

Reassigning all automatically assigned bugs from Mostafa to nobody@m.o

Bugspam filter: TorontoMostafaMove

Comment 13

[Stefan Sitter [:ssitter]]

As I understood recent decisions we are not going to do alpha or beta releases anymore. All released versions will have a version number that look like "0.m" (e.g. 0.3, 0.5).

Therefore we only need to agree on a version number scheme between releases. 

After looking at https://addons.mozilla.org/faq.php and 
http://developer.mozilla.org/en/docs/Toolkit_version_format#Version_format
I suggest to follow the scheme that is already used by Firefox and Thunderbird using "0.na1". 

That means for Sunbird/Lightning:
 0.3            Released build (current)
 0.4a1 or 0.5a1 Nightly builds
 0.5            Released build (upcoming)

Comment 14

[Martin Schröder [:mschroeder]]

*** Bug 349350 has been marked as a duplicate of this bug. ***

Comment 15

[Matthew (lilmatt) Willis]

This is for use immediately after 0.3 gets released.

ssitter: Please be sure this is covered in your release checklist

Comment 16

[Matthew (lilmatt) Willis]

When I cut the SUNBIRD_0_3_BRANCH, I bumped version.txt on trunk to 0.4a1 per this.

-> FIXED