394037 - Version/config bumps for Gecko1.9a8 release

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Placeholder bug for the gecko1.9a8 release. Waiting for development codefreeze.

Comment 1

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Attachment: bump version to 3.0a8/1.9a8

Comment 2

[J. Paul Reed [:preed]]

Comment on attachment 280529 [details] [diff] [review]
bump version to 3.0a8/1.9a8

You're bumping the versions on the MOZILLA_1_9a7_MINIBRANCH.

You need to create a MOZILLA_1_9a8_MINIBRANCH of these files, and make the change there.

Comment 3

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Attachment: bump version to 3.0a8/1.9a8

Comment 4

[J. Paul Reed [:preed]]

Comment on attachment 280536 [details] [diff] [review]
bump version to 3.0a8/1.9a8

Looks good; please land on the MOZILLA_1_9a8_MINIBRANCH branch.

Comment 5

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

(In reply to comment #4)
> (From update of attachment 280536 [details] [diff] [review])
> Looks good; please land on the MOZILLA_1_9a8_MINIBRANCH branch.
> 

Done.

Comment 6

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Attachment: changes to linux/win32/macosx tinder_config.pl files

Comment 7

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Attachment: Bump version to 3.0b1pre/1.9b1pre

Confirmed this morning that next milestone (m9) is actually going to be first beta, hence used "b1", not "a9".

Comment 8

[Benjamin Smedberg]

I don't think we want to bump to b1pre... we can take the trunk to a9pre and then jump directly to b1 for the next release. That will future-proof any beta repositioning that might happen.

Comment 9

[J. Paul Reed [:preed]]

(In reply to comment #8)
> I don't think we want to bump to b1pre... we can take the trunk to a9pre and
> then jump directly to b1 for the next release. That will future-proof any beta
> repositioning that might happen.

I was looking through this, and I agree...

I was also going to suggest changing to four-digit version numbers (assuming we're using the same model we used in 2.0.0.x).

We did this change for Thunderbird 2.0.0.0 because it's weird to have the length of the version number change between 2.0 and 2.0.0.1. 2.0 really should be 2.0.0.0.

If we're doing that for Firefox 3, these values should probably be 3.0.0.0a9pre and 1.9.0.0a9pre, etc.

(This isn't to say it has any effect on how we present this information to the user; we could easily parse out the version number and on a version of 3.x.y.z, do something like "Version 3.x, Update z" or whatever in the UI.)

Comment 10

[Benjamin Smedberg]

FWIW, we are going to switch to 3-digit versions for FF3, so it will be FF3.0.1, 3.0.2, etc.

The gecko numbers will remain 4-digit, e.g. 1.9.0.1, 1.9.0.2

Comment 11

[J. Paul Reed [:preed]]

Comment on attachment 280548 [details] [diff] [review]
changes to linux/win32/macosx tinder_config.pl files

I didn't see this review in time :-( It looks fine, but since 1.9a8 already went out, I'll cancel.

Comment 12

[J. Paul Reed [:preed]]

(In reply to comment #10)
> FWIW, we are going to switch to 3-digit versions for FF3, so it will be
> FF3.0.1, 3.0.2, etc.
> 
> The gecko numbers will remain 4-digit, e.g. 1.9.0.1, 1.9.0.2

Oh, that's cool!

So, I just don't think they should be changing lengths. I'll go ahead and r- based on this, and that we should probably do a9 instead.

Comment 13

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Attachment: Bump version to 3.0a9pre/1.9a9pre

1) changed to 1.9a9 as reviewed.

2) didnt follow the 3.0.0 vs 3.0.0.0 discussion. Is this related to my version bump change?

Comment 14

[J. Paul Reed [:preed]]

Comment on attachment 281760 [details] [diff] [review]
 Bump version to 3.0a9pre/1.9a9pre  

(In reply to comment #13)
> Created an attachment (id=281760) [details]

> 2) didnt follow the 3.0.0 vs 3.0.0.0 discussion. Is this related to my version
> bump change?

Kinda; if we're going to make this change to constant-length version numbers--and I think we should, and based on my impression, I think bsmedberg is for it--we should do that before the beta, and it would be nice to do it at a version bump point.

For patches, can you use diff -u please? It helps when reviewing.

Comment 15

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Attachment: Bump version to 3.0a9pre/1.9a9pre

Comment 16

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

1) per offline discussion, separating version schema discussion out from this.

2) redo patch with "cvs diff -u". Did that the first time, but forgot it the 2nd time. Sorry.

Comment 17

[J. Paul Reed [:preed]]

Comment on attachment 281852 [details] [diff] [review]
 Bump version to 3.0a9pre/1.9a9pre  

As cf said:

2:35 < cf-afk> don't forget the tinder-config.pl for the perf boxes, that's 
mozilla/tools/tinderbox-configs/firefox/{win32,linux}/tinder-config.pl on the 
                test_perf branch
12:35 < cf-afk> and 
                mozilla/tools/tinderbox-configs/{Firefox,XULRunner}_trunk.txt

I'll review those if you do a patch for it; please do not land this before those changes are ready to land simultaneously.

Comment 18

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: bumps for perf tests and nagios monitoring

Comment 19

[Nick Thomas [:nthomas] (UTC+12)]

For version changes on the Firefox trunk you need to update
  mozilla/tools/tinderbox-configs/firefox/win32/tinder-config.pl
  mozilla/tools/tinderbox-configs/firefox/linux/tinder-config.pl
from the perf_test tag of CVS. The value of $DownloadBuildFile needs changing so these boxes pull the right hourly builds from the ftp server. Same for the 1.8 branch only you use the MOZILLA_1_8_BRANCH_perf_test tag.

For all releases you need to update
  mozilla/tools/tinderbox-configs/$app_$branch.txt
from the HEAD tag of CVS. eg
  mozilla/tools/tinderbox-configs/Firefox_trunk.txt
This keeps nagios watching the $app/latest-$branch directory on the ftp, if the files go stale then a tinderbox has gone missing.

If you change milestone.txt then you should also change
  mozilla/tools/tinderbox-configs/XULRunner_$branch.txt

Comment 20

[Nick Thomas [:nthomas] (UTC+12)]

Let's try that again (pls ignore comment #19)

For version changes on the Firefox trunk you need to update
  mozilla/tools/tinderbox-configs/firefox/win32/tinder-config.pl
  mozilla/tools/tinderbox-configs/firefox/linux/tinder-config.pl
from the perf_test tag of CVS. The value of $DownloadBuildFile needs changing
so these boxes pull the right hourly builds from the ftp server. The same goes for the version bumps on the 1.8 branch, only you use the MOZILLA_1_8_BRANCH_perf_test tag.

For all releases you need to update
  mozilla/tools/tinderbox-configs/monitoring/$app_$branch.txt
from the HEAD tag of CVS. eg
  mozilla/tools/tinderbox-configs/monitoring/Firefox_trunk.txt
This keeps nagios watching the $app/nightly/latest-$branch/ directory on the ftp, if the files go stale then a tinderbox has gone missing and we can restart it.

If you change mozilla/config/milestone.txt for the version bump then you should also change
  mozilla/tools/tinderbox-configs/monitoring/XULRunner_$branch.txt
This happens for Firefox bumps but not other apps.

Comment 21

[Nick Thomas [:nthomas] (UTC+12)]

Both bump patches landed. That's the normal point to close a release bug, but I'll leave that to John (as the assignee).

Comment 22

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Many thanks Nick!

Comment 23

[pal-moz]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007092118 Minefield/3.0a9pre ID:2007092118

rv is still 1.9a8pre.

Comment 24

[Nick Thomas [:nthomas] (UTC+12)]

(In reply to comment #23)
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007092118
> Minefield/3.0a9pre ID:2007092118
> 
> rv is still 1.9a8pre.

It's normal for that to happen, the change is picked up by a nightly (or other clobber) build.