[development_specifics] Version numbers for Firefox 5+
Christian Legnitto
I have updated http://mozilla.github.com/process-releases/draft/development_specifics/ with the current version number plan. Unless there are major problems this is the way we are going to go. Thanks to everyone for their comments and to bsmedberg and KaiRo specifically for their detailed suggestions.
Please respond here with any SHOWSTOPPING issues. There is no right answer for the version numbers and we are at the point where we need to pick one and go with it.
Thanks,
Christian
beltzner
Thanks for continuing to work and update everyone on this document. It's looking good and reads very clearly.
It was my understanding that merges from aurora -> beta and beta -> release were to be gated by a "go/no-go" decision from project and product stakeholders (dev, QA, marketing, product management, etc) but this document implies that all merges are automatic and date-driven. Had I misunderstood, or is the document referring to the merge from mozilla-central -> aurora only?
If the merges are not automatic, then I would assume that we'd only bump the version numbers down the line when a new merge comes across. There is then an edge case scenario where mozilla-central and mozilla-aurora (the former automatically merging to the latter) would be multiple version numbers ahead of mozilla-beta and mozilla-release. This can be solved by either holding version number increments to times when we merge from mozilla-aurora to mozilla-beta, or we could just skip version numbers on mozilla-beta and mozilla-release. Either is fine, but I think we need to understand our preferred approach ahead of time.
cheers,
mike
beltzner
Christian Legnitto
Thanks,
Christian
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
RyanVM
> >https://lists.mozilla.org/listinfo/dev-planning
Would mozilla-shadow be merged into mozilla-central at the same time
that it's merged into mozilla-aurora? If so, would it be easier to
just merge it to m-c and then proceed with the usual m-c-->m-a merge?
Daniel Cater
How often are updates pushed on the "aurora" and beta channels? What about this versioning scheme:
nightly channel: 5.0a0 (nightly, duh)
alpha channel: 5.0a1, 5.0a2, 5.0a3... (nightly? every few days?)
beta channel: 5.0b1, 5.0b2, 5.0b3... (weekly?)
release channel: 5.0, 5.1, 5.2... (minimal number of point releases expected, multiple weeks apart)
Also if the only reason to remove the "pre" was for Palm Pre confusion, you could use "p" in the interim builds between channel pushes.
How do you achieve "Ability to identify which channel a user is on from the build" without having separate version numbers for the beta channel? With things like pipelining in the pipeline (aha), it would be really useful if webmasters could say what was causing their server to crash etc. I understand the desire for "Beta and release versions should identify as the same version to make sure beta testing is valid and no last-minute issues are found due to a version change" but there will still be an RC or 2 right?
I think the ability to distinguish pre-release builds server side is useful and outweighs the (decreasingly-common) UA-sniffing issues.
Daniel Cater
Armen Zambrano Gasparnian
> Why "mozilla-aurora" and not "mozilla-alpha"? I couldn't find that information anywhere.
>
plays well with "nightly" (after the night the dawn comes).
> How often are updates pushed on the "aurora" and beta channels? What about this versioning scheme:
>
> nightly channel: 5.0a0 (nightly, duh)
> alpha channel: 5.0a1, 5.0a2, 5.0a3... (nightly? every few days?)
There is no real reason to be bumping the version on every build as we
have the buildid to identify the builds on bug reporting.
Daniel Cater
For Mozilla's purposes, sure, you can just ask the bug reporter to get it from about:support or something.
Christian Legnitto
On Apr 7, 2011, at 10:13 AM, Daniel Cater wrote:
> The build id is only useful to webmasters as long as it reflects reality in the UA. This is currently not true for beta and release builds, but the version still changes between beta builds. Now, different beta builds will look the same and I worry that this will cause problems.
The changes between beta and release will be minimal. Think of it as the difference between Fierfox 4 RC 1 and Firefox 4 final.
Additionally, this is no different for how the current older branch releases are identified. The beta builds on those channels identify exactly the same as the final bits.
Thanks,
Christian
Christian Legnitto
On Apr 7, 2011, at 9:50 AM, Daniel Cater wrote:
> Why "mozilla-aurora" and not "mozilla-alpha"? I couldn't find that information anywhere.
This was generally rejected due to alpha having existing connotations. Aurora could be crashier than an alpha. Also, it is better to talk about Aurora as a separate entity rather than an alpha of Firefox (which is why the branding is different).
> How often are updates pushed on the "aurora" and beta channels? What about this versioning scheme:
aurora is nightly (assuming there are changes to the repo). For beta we want to get to that scheme as well but automation prevents this. Instead it will initially be weekly or bi-weekly (depending on the fixes needed and the cost to RelEng).
> nightly channel: 5.0a0 (nightly, duh)
> alpha channel: 5.0a1, 5.0a2, 5.0a3... (nightly? every few days?)
> beta channel: 5.0b1, 5.0b2, 5.0b3... (weekly?)
> release channel: 5.0, 5.1, 5.2... (minimal number of point releases expected, multiple weeks apart)
We don't want betas to identify differently than release so we can be confident the testing on beta applies to release. Additionally, we didn't want to start with 0 as current tools may not cope with that (we've always started *a* version numbers with 1 I believe.
Additionally, we don't expect point releases. The "point" release for Firefox 5 is Firefox 6. The only point releases will be for out-of-band chemspill issues (like active exploits and newly found, major stability issues).
> How do you achieve "Ability to identify which channel a user is on from the build" without having separate version numbers for the beta channel?
The idea in general is there should be no difference between beta and final from a web developer side. You can still discern between "may change every day" (a1) "prerelease, generally done but may change a bit" (a2) and "locked down / very close to release / release" ([^a]). You can then slice those by version if so desired.
> With things like pipelining in the pipeline (aha), it would be really useful if webmasters could say what was causing their server to crash etc. I understand the desire for "Beta and release versions should identify as the same version to make sure beta testing is valid and no last-minute issues are found due to a version change" but there will still be an RC or 2 right?
No, the last build pushed to beta is the one that will be pushed to release (I'm hand-waiving about some release engineering mechanics here). In the best case we do 1 build on beta, don't find any issues for 6 weeks, and then release that as final.
> I think the ability to distinguish pre-release builds server side is useful and outweighs the (decreasingly-common) UA-sniffing issues.
Again, think of beta more like Firefox 4 RC1-2, not beta 1-12.
Thanks,
Christian
Frédéric Buclin
> Additionally, we don't expect point releases. The "point" release for
> Firefox 5 is Firefox 6.
I didn't read all comments as there were just too many recently, so
maybe this was already answered elsewhere, but is an extension working
with Firefox 5 automatically working with Firefox 6 too? Because if
that's not the case, then this means that when something is broken in
Fx5 and Fx devs say "you should upgrade to Fx6 to have the fix", you are
in a situation where you have to choose between a broken feature in Fx5
but working extensions, or a fixed feature in Fx6 but non-working
extensions. I'm pretty sure not all extensions will be updated at the
same rate as Fx releases, and this is going to trigger a lot of pain for
all of us who use quite a few extensions. Having point releases would
allow us to have both the fix in e.g. Fx 5.0.1 *and* extensions still
working (my feeling is that your new release cycle is too fast, and some
companies or individuals like me who need extensions to be working will
skip some releases and jump e.g. from Fx4 to Fx6 or Fx7 directly, or
jump to Fx5 when Fx6 is already released, because we are waiting for all
installed extensions to be compatible with a given release before
upgrading, making us to be always behind, including for security fixes).
LpSolit
Daniel Cater
> We don't want betas to identify differently than release so we can be confident the testing on beta applies to release. Additionally, we didn't want to start with 0 as current tools may not cope with that (we've always started *a* version numbers with 1 I believe.
Do you know of any current tools that won't cope? The client-side and server-side version comparison code should work I think. I think "a0" could work well as the new way of saying "a1pre".
> Additionally, we don't expect point releases. The "point" release for Firefox 5 is Firefox 6. The only point releases will be for out-of-band chemspill issues (like active exploits and newly found, major stability issues).
Right, but at some point it will happen and you need to have a plan for versioning. Is 5.1 a reasonable version for the first out-of-band update for Fx 5? Now that the standard major/minor/patch versioning system is out of the window and every time-based release bumps the major version number I see no reason to call it 5.0.1 (or worse, 5.0.0.1 as the 2.0 branch did).
> > How do you achieve "Ability to identify which channel a user is on from the build" without having separate version numbers for the beta channel?
>
> The idea in general is there should be no difference between beta and final from a web developer side. You can still discern between "may change every day" (a1) "prerelease, generally done but may change a bit" (a2) and "locked down / very close to release / release" ([^a]). You can then slice those by version if so desired.
OK. So all betas will have the same version number, and that will be the version number of the final release? And each aurora update will have the same version as the previous one?
> Again, think of beta more like Firefox 4 RC1-2, not beta 1-12.
OK, if that's the case then I agree that having it reflect the final release as closely as possible is a good idea.
Daniel Cater
> We don't want betas to identify differently than release so we can be confident the testing on beta applies to release. Additionally, we didn't want to start with 0 as current tools may not cope with that (we've always started *a* version numbers with 1 I believe.
Do you know of any current tools that won't cope? The client-side and server-side version comparison code should work I think. I think "a0" could work well as the new way of saying "a1pre".
> Additionally, we don't expect point releases. The "point" release for Firefox 5 is Firefox 6. The only point releases will be for out-of-band chemspill issues (like active exploits and newly found, major stability issues).
Right, but at some point it will happen and you need to have a plan for versioning. Is 5.1 a reasonable version for the first out-of-band update for Fx 5? Now that the standard major/minor/patch versioning system is out of the window and every time-based release bumps the major version number I see no reason to call it 5.0.1 (or worse, 5.0.0.1 as the 2.0 branch did).
> > How do you achieve "Ability to identify which channel a user is on from the build" without having separate version numbers for the beta channel?
>
> The idea in general is there should be no difference between beta and final from a web developer side. You can still discern between "may change every day" (a1) "prerelease, generally done but may change a bit" (a2) and "locked down / very close to release / release" ([^a]). You can then slice those by version if so desired.
OK. So all betas will have the same version number, and that will be the version number of the final release? And each aurora update will have the same version as the previous one?
> Again, think of beta more like Firefox 4 RC1-2, not beta 1-12.
OK, if that's the case then I agree that having it reflect the final release as closely as possible is a good idea.
Daniel Cater
Are you sure? Open up Fx4b11 and Fx4b12 and compare the "UserAgent from header" here: http://browserspy.dk/useragent.php
Daniel Cater
Are you sure? Open up Fx4b11 and Fx4b12 and compare the "UserAgent from header" here: http://browserspy.dk/useragent.php
Christian Legnitto
On Apr 8, 2011, at 9:07 AM, Daniel Cater wrote:
>> Additionally, this is no different for how the current older branch releases are identified. The beta builds on those channels identify exactly the same as the final bits.
>
> Are you sure? Open up Fx4b11 and Fx4b12 and compare the "UserAgent from header" here: http://browserspy.dk/useragent.php
I was talking about the security and stability beta releases for 3.5 and 3.6. We push those to the beta audience for a week or so, and if no problems are found push them to the release audience without rebuilding.
Christian Legnitto
On Apr 8, 2011, at 9:03 AM, Daniel Cater wrote:
> Thanks for responding. So to clarify a few things:
No problem, happy to clarify our thinking.
>
>> We don't want betas to identify differently than release so we can be confident the testing on beta applies to release. Additionally, we didn't want to start with 0 as current tools may not cope with that (we've always started *a* version numbers with 1 I believe.
>
> Do you know of any current tools that won't cope? The client-side and server-side version comparison code should work I think. I think "a0" could work well as the new way of saying "a1pre".
The tools I was talking about are Mozilla-related tools (crash-stats, the build system, metrics reports, etc). Sure, some of them may cope with a different scheme but we are fairly confident without an audit that the changes for this scheme will be minimal and if no changes happen the tools won't fall over.
>
>> Additionally, we don't expect point releases. The "point" release for Firefox 5 is Firefox 6. The only point releases will be for out-of-band chemspill issues (like active exploits and newly found, major stability issues).
>
> Right, but at some point it will happen and you need to have a plan for versioning. Is 5.1 a reasonable version for the first out-of-band update for Fx 5? Now that the standard major/minor/patch versioning system is out of the window and every time-based release bumps the major version number I see no reason to call it 5.0.1 (or worse, 5.0.0.1 as the 2.0 branch did).
If needed, the chemspill for 5.0 will be 5.0.1 (haven't had time to update the chemspill section yet but we have it pretty nailed down). This makes it so tools and web sites can only look at the 1st 2 digits if they only care about the "family". In general, 5.0.1 should be exactly the same as 5.0 and tools/websites should be able to group accordingly. I don't think we want 5.1 as tools/websites may still see the 2nd number as significant (as it was for 3.5 -> 3.6).
>
>>> How do you achieve "Ability to identify which channel a user is on from the build" without having separate version numbers for the beta channel?
>>
>> The idea in general is there should be no difference between beta and final from a web developer side. You can still discern between "may change every day" (a1) "prerelease, generally done but may change a bit" (a2) and "locked down / very close to release / release" ([^a]). You can then slice those by version if so desired.
>
> OK. So all betas will have the same version number, and that will be the version number of the final release? And each aurora update will have the same version as the previous one?
Yes.
>
>> Again, think of beta more like Firefox 4 RC1-2, not beta 1-12.
>
> OK, if that's the case then I agree that having it reflect the final release as closely as possible is a good idea.
Great, glad you agree with our reasoning. I know naming the channel as "beta" is confusing if it is going to feel more like our RCs....but I think we are merely getting back to the traditional definition of a beta...
Thanks,
Christian
Millwood
>> Additionally, this is no different for how the current older branch releases are identified. The beta builds on those channels identify exactly the same as the final bits.
>
> Are you sure? Open up Fx4b11 and Fx4b12 and compare the "UserAgent from header" here: http://browserspy.dk/useragent.php
the useragent string is available in about:support
Daniel Cater
> >
> > Are you sure? Open up Fx4b11 and Fx4b12 and compare the "UserAgent from header" here: http://browserspy.dk/useragent.php
>
> I was talking about the security and stability beta releases for 3.5 and 3.6. We push those to the beta audience for a week or so, and if no problems are found push them to the release audience without rebuilding.
Ah, OK, that's not what I thought you were referring to. Whilst those users were on the "beta" channel, the updates were not really betas, but RCs (to use the previous terminology). The sizes of the changes were much smaller than in the betas that were released for Fx4.
This is largely irrelevant though if new betas are going to be more like old-school RCs (which I think is a good thing).
Daniel Cater
> >
> > Are you sure? Open up Fx4b11 and Fx4b12 and compare the "UserAgent from header" here: http://browserspy.dk/useragent.php
>
> I was talking about the security and stability beta releases for 3.5 and 3.6. We push those to the beta audience for a week or so, and if no problems are found push them to the release audience without rebuilding.
Ah, OK, that's not what I thought you were referring to. Whilst those users were on the "beta" channel, the updates were not really betas, but RCs (to use the previous terminology). The sizes of the changes were much smaller than in the betas that were released for Fx4.
Ryan VanderMeulen
tracking m-c and being merged into m-a along with m-c at the designated
merge point. Would m-s be merged into m-c at the same time that it's merged
into m-a? If so, would it be easier to just merge it to m-c and then proceed
Benjamin Smedberg
--BDS
Ryan VanderMeulen <rya...@gmail.com> wrote:
John O'Duinn
On 4/9/11 12:01 PM, Benjamin Smedberg wrote:
> Yes. That's a good suggestion.
Agreed. It has less mechanical steps, so less opportunity to go wrong,
so I like this suggestion also.
> AFAIK we don't have the shadow repository in place yet, so this cycle isn't affected anyway.
The shadow repo has been up and running since last year - contact
ladamski, dveditz or myself for further details.
Whether there is anything there waiting to land and approved for FF5.0
is up to release managers.
> --BDS
tc
John.
=====
Phil Ringnalda
>> AFAIK we don't have the shadow repository in place yet, so this cycle isn't affected anyway.
> The shadow repo has been up and running since last year - contact
> ladamski, dveditz or myself for further details.
>
> Whether there is anything there waiting to land and approved for FF5.0
> is up to release managers.
Some permaorange failures, some known intermittent, some unknown
intermittent - I look forward to seeing how they're going to deal with
crashlanding a bunch of things that nobody has ever looked at the
results of.