Version/config bumps for Gecko1.9a8 release

RESOLVED FIXED

Status

P2
normal
RESOLVED FIXED
11 years ago
5 years ago

People

(Reporter: joduinn, Assigned: joduinn)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments, 3 obsolete attachments)

Placeholder bug for the gecko1.9a8 release. Waiting for development codefreeze.
Priority: -- → P3
Assignee: build → joduinn
Priority: P3 → P2
Whiteboard: waiting for code freeze
Created attachment 280529 [details] [diff] [review]
bump version to 3.0a8/1.9a8
Attachment #280529 - Flags: review?(preed)
Attachment #280529 - Flags: review?(rhelmer)

Comment 2

11 years ago
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.
Attachment #280529 - Flags: review?(preed) → review-
Attachment #280529 - Flags: review?(rhelmer)
Created attachment 280536 [details] [diff] [review]
bump version to 3.0a8/1.9a8
Attachment #280529 - Attachment is obsolete: true
Attachment #280536 - Flags: review?(preed)

Comment 4

11 years ago
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.
Attachment #280536 - Flags: review?(preed) → review+
(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.
Status: NEW → ASSIGNED
Created attachment 280548 [details] [diff] [review]
changes to linux/win32/macosx tinder_config.pl files
Attachment #280548 - Flags: review?(preed)
Whiteboard: waiting for code freeze → builds being tested by QA - waiting for results
Created attachment 281737 [details] [diff] [review]
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".
Attachment #281737 - Flags: review?(preed)

Comment 8

11 years ago
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

11 years ago
(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

11 years ago
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 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.
Attachment #280548 - Flags: review?(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.

Updated

11 years ago
Attachment #281737 - Flags: review?(preed) → review-
Created attachment 281760 [details] [diff] [review]
 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?
Attachment #281737 - Attachment is obsolete: true
Attachment #281760 - Flags: review?(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.
Attachment #281760 - Flags: review?(preed) → review-
Created attachment 281852 [details] [diff] [review]
 Bump version to 3.0a9pre/1.9a9pre
Attachment #281760 - Attachment is obsolete: true
Attachment #281852 - Flags: review?(preed)
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 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.
Attachment #281852 - Flags: review?(preed) → review+
Created attachment 281863 [details] [diff] [review]
bumps for perf  tests and nagios monitoring
Attachment #281863 - Flags: review?(preed)
Attachment #281863 - Attachment is patch: true
Attachment #281863 - Attachment mime type: application/octet-stream → text/plain
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
Whiteboard: builds being tested by QA - waiting for results
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.

Updated

11 years ago
Attachment #281863 - Flags: review?(preed) → review+
Both bump patches landed. That's the normal point to close a release bug, but I'll leave that to John (as the assignee).
Many thanks Nick!
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED

Comment 23

11 years ago
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.
(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.
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.