Closed Bug 315315 Opened 19 years ago Closed 18 years ago

Name nightlies so they sort after 0.3a1 by version comparator

Categories

(Calendar :: Sunbird Only, defect)

x86
Windows 2000
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED
Sunbird 0.5

People

(Reporter: gekacheka, Unassigned)

References

Details

Attachments

(1 file)

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 '+')
(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.+")
Attachment #202034 - Flags: first-review?(mvl)
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.
(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.
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 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.
Attachment #202034 - Flags: first-review?(mvl) → first-review-
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.
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.
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.
Depends on: 313605
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)
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?
*** Bug 322508 has been marked as a duplicate of this bug. ***
Reassigning all automatically assigned bugs from Mostafa to nobody@m.o Bugspam filter: TorontoMostafaMove
Assignee: mostafah → nobody
Component: General → Sunbird Only
Target Milestone: --- → Sunbird 0.3
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)
*** Bug 349350 has been marked as a duplicate of this bug. ***
This is for use immediately after 0.3 gets released. ssitter: Please be sure this is covered in your release checklist
Target Milestone: Sunbird 0.3 → Sunbird 0.4
QA Contact: general → sunbird
When I cut the SUNBIRD_0_3_BRANCH, I bumped version.txt on trunk to 0.4a1 per this. -> FIXED
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: