Set version to 0.4a1; Remove workarounds for 0.3 release; Sync mozilla1.8 branch and trunk

RESOLVED FIXED

Status

defect
RESOLVED FIXED
13 years ago
13 years ago

People

(Reporter: ssitter, Assigned: ssitter)

Tracking

Details

Attachments

(1 attachment, 1 obsolete attachment)

We should set version number to 0.4a1 and remove workarounds for 0.3 release to sync mozilla1.8 branch and trunk.
Posted patch patch for MOZILLA_1_8_BRANCH (obsolete) — Splinter Review
Attachment #242318 - Flags: first-review?(lilmatt)
Comment on attachment 242318 [details] [diff] [review]
patch for MOZILLA_1_8_BRANCH

>Index: mozilla/calendar/locales/all-locales
>===================================================================
>-lt
lt has a localization on branch, but not trunk. Leave this branch/trunk discrepancy alone.

r=lilmatt without that edit
Attachment #242318 - Flags: first-review?(lilmatt) → first-review+
Address nits. Carry over r+ from lilmatt
Attachment #242325 - Flags: second-review?(jminta)
Attachment #242325 - Flags: first-review+
Comment on attachment 242325 [details] [diff] [review]
patch for MOZILLA_1_8_BRANCH, v2 (checked in)

>-WIN32_MODULE_FILEVERSION=0,3,0,0
>-WIN32_MODULE_FILEVERSION_STRING=0.3
>+WIN32_MODULE_FILEVERSION=0,3,9,0
>+WIN32_MODULE_FILEVERSION_STRING=0.4a1

Let's grant ourselves some more room, by using 0,3,1,0 or so. Also, why not 0.3.1, to avoid the messy, not sortable, alpha strings in the version number?
(In reply to comment #4)
> >+WIN32_MODULE_FILEVERSION=0,3,9,0
> >+WIN32_MODULE_FILEVERSION_STRING=0.4a1
> Let's grant ourselves some more room, by using 0,3,1,0 or so. Also, why not
> 0.3.1, to avoid the messy, not sortable, alpha strings in the version number?

This is to match trunk, which currently uses 0,3,9,0 and 0.4a1 as was suggested in some bug a while back.

Why doesn't the last zero give us enough room in the 0,3,9,0?
(In reply to comment #4)

Bug 315315 was about the nightly version number issue. The sort problem only occurred when using something like 0.3a1+. 0.3a1 or 0.4a1 causes no problems.

There was also IRC discussion at the end of August and the conclusion was to go on with 0.4a1 and make the next release 0.5. It also follows the version scheme used by Firefox/Thunderbird at the moment.
That 9 makes that number basically useless, because we can't change it anymore.
What bug discussed the new version number for trunk? Can we still change trunk back?
Comment on attachment 242325 [details] [diff] [review]
patch for MOZILLA_1_8_BRANCH, v2 (checked in)


-<!-- Commented out for 0.3 release
     <hbox id="ltnDateTextPickerBox">
       <spacer flex="1"/>
       <datepicker id="ltnDateTextPicker" oncommand="ltnGoToDate()"/>
       <spacer flex="1"/> 
     </hbox>
--->
Let's get a quick audit to make sure we have the relevant bugs open to properly fix this mess.

I'll do a final pass once mvl's concerns are worked out.
(In reply to comment #8)
> Let's get a quick audit to make sure we have the relevant bugs 
> open to properly fix this mess.

Bug 351380, once we sync branch and trunk work can go on.

> I'll do a final pass once mvl's concerns are worked out.

Is there a real reason to recall the decision made to bump the version number to 0.4a1 for nightly builds? (And that is already used on trunk) Toolkits VersionComparator and addons.mozilla.org have no problems with this.
Comment on attachment 242325 [details] [diff] [review]
patch for MOZILLA_1_8_BRANCH, v2 (checked in)

r2=jminta
Attachment #242325 - Flags: second-review?(jminta) → second-review+
Attachment #242318 - Attachment is obsolete: true
Comment on attachment 242325 [details] [diff] [review]
patch for MOZILLA_1_8_BRANCH, v2 (checked in)

This patch checked in on MOZILLA_1_8_BRANCH only.

Leaving bug open for similar fixes for trunk.
Attachment #242325 - Attachment description: patch for MOZILLA_1_8_BRANCH, v2 → patch for MOZILLA_1_8_BRANCH, v2 (checked in)
(In reply to comment #11)
> Leaving bug open for similar fixes for trunk.

No changes to trunk required. MOZILLA_1_8_BRANCH and trunk are now synced.

-> FIXED
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.