New version bump process for Firefox 2.0.0.x

[J. Paul Reed]

Hey all:

We've been using a new version bump process for the 1.8.0branch/1.5.0.x
releases for a couple of releases now and I'd like to start using it for
the 1.8 branch/2.0.x.y releases.

The basic process is:

1. A version is released, Firefox 1.5.0.8, let's say

2. When the tree opens for 1.5.0.9 checkins, the version is bumped to
"1.5.0.9pre"

3. Upon reaching code complete, the version numbers are bumped to
"1.5.0.9" until 1 is reached. Rinse and repeat.

This is similar to the "version_number+" days, but it uses something
that is more readable, and not a version "wildcard character." It also
works with extension compatibility checks and AUS.

When we were first kicking around this idea, we discussed it with the QA
and release teams for both Firefox and Thunderbird on the 1.8.0 branch.

It took a little bit of getting used to at first, but it's worked out
really well in terms of being able to easily see at a glance which
nightly build you have, and which part of the release process that build
is a part of.

It's also helped the release team in terms of being able to have
noticeable boundaries upon entering and exiting certain phases of the
release of maintenance releases.

You can see how the process was used by looking through bugs 348117
(1.5.0.7), 353178 (1.5.0.8), and 360034 (1.5.0.9).

I'd like to use this same methodology for 2.0.0.1 (despite the fact that
code has already gone in for 2.0.0.1; we don't always catch the tree
reopening. We should probably be better about that. :-)

Thoughts?

Later,
preed
--
J. Paul Reed
Build/Release Engineer - The Mozilla Corporation
smtp://pr...@mozilla.com
irc://irc.mozilla.org/preed
pots://650.903.0800/x256

[Axel Hecht]

Does that somehow affect the gecko versioning of Thunderbird? And is
that the right thing to do?

Axel

[J. Paul Reed]

Axel Hecht wrote:

> J. Paul Reed wrote:
>
>> Thoughts?
>
> Does that somehow affect the gecko versioning of Thunderbird? And is
> that the right thing to do?

It typically does, yes.

And I think so, since Thunderbird is getting the new gecko code when it
builds. If it were building a static tag of things like mozilla/js and
the shared Gecko stuff it uses, then it wouldn't be. But it's building
latest, so it should get the version bump.

[Mike Beltzner]

Paul,

I definitely like the idea of setting these builds apart at the version number level. Some questions:

- how will this affect extension compatibility checking?

- what do you mean "until 1 is reached"

- will this result in the build names changing to "firefox1.5.0.9.pre"?

cheers,
mike

[J. Paul Reed]

Mike Beltzner wrote:
> Paul,
>
> I definitely like the idea of setting these builds apart at the version number level. Some questions:
>
> - how will this affect extension compatibility checking?

We haven't had any problems reported from using this method for Firefox
1.5.0.x (or Thunderbird, for that matter). When discussing this change,
we talked it over with bsmedberg and rstrong, and specifically picked
the "pre" suffix because the various version compatibility checks were
supposed to handle that (as opposed to not handling the "+" very well :-)

> - what do you mean "until 1 is reached"

There's a window of time between code complete and release where we're
doing any necessary respins. The version number would remain 1.5.0.9 (or
2.0.0.1, or whatever) for those respins.

So:

Pre-code complete: 2.0.0.1pre
Code complete/RC 1 spin: 2.0.0.1
RC 2 spin: 2.0.0.1
RC 3 spin: 2.0.0.1
RC N spin: 2.0.0.1
Release: 2.0.0.1
Pre-code complete for next release: 2.0.0.2pre

I've been mulling around only making the version changes on the
_MINIBRANCHES, so nightlies will always have a "pre" appended to them,
and only the releases will get the actual version numbers, but that's
another issue entirely.

> - will this result in the build names changing to "firefox1.5.0.9.pre"?

You mean in like FTP and stuff? Yes, it will; see

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2006-11-09-05-mozilla1.8.0

for an example.

[Robert Kaiser]

J. Paul Reed schrieb:

> This is similar to the "version_number+" days, but it uses something
> that is more readable, and not a version "wildcard character." It also
> works with extension compatibility checks and AUS.

I heard that AMO chokes on the current "2.0b1pre" version of
Thunderbird on the 1.8 branch and tells users that a dirctionary marked
compatible with 2.0a1 - 3.0a1 is not compatible with 2.0b1pre, actually.

Robert Kaiser

[Mike Shaver]

On 11/10/06, Robert Kaiser <ka...@kairo.at> wrote:
> I heard that AMO chokes on the current "2.0b1pre" version of
> Thunderbird on the 1.8 branch and tells users that a dirctionary marked
> compatible with 2.0a1 - 3.0a1 is not compatible with 2.0b1pre, actually.

Is there a bug number for that?

(This is a great example of why it's nice to verify that things which
are "supposed to handle that" actually do, in the deployed systems,
but here we are!)

Mike

[Robert Kaiser]

Mike Shaver schrieb:

I don't think there's a bug, I had other stuff to concentrate upon when
someone pinged me on IRC about that...
It should be filed probably... But again, now is a bad time for me to do
it, as I'm too busy atm. :(

Robert Kaiser