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

Status: RESOLVED FIXED

(Calendar :: General, defect)

Description

[Stefan Sitter [:ssitter]]

We should set version number to 0.4a1 and remove workarounds for 0.3 release to sync mozilla1.8 branch and trunk.

Comment 1

[Stefan Sitter [:ssitter]]

Attachment: patch for MOZILLA_1_8_BRANCH

Comment 2

[Matthew (lilmatt) Willis]

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

Comment 3

[Stefan Sitter [:ssitter]]

Attachment: patch for MOZILLA_1_8_BRANCH, v2 (checked in)

Address nits. Carry over r+ from lilmatt

Comment 4

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

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?

Comment 5

[Matthew (lilmatt) Willis]

(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?

Comment 6

[Stefan Sitter [:ssitter]]

(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.

Comment 7

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

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 8

[Joey Minta]

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.

Comment 9

[Stefan Sitter [:ssitter]]

(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 10

[Joey Minta]

Comment on attachment 242325 [details] [diff] [review]
patch for MOZILLA_1_8_BRANCH, v2 (checked in)

r2=jminta

Comment 11

[Matthew (lilmatt) Willis]

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.

Comment 12

[Stefan Sitter [:ssitter]]

(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