Yes, there will be a Firefox 4 .x release
Christian Legnitto
Please note that this plan does not have any bearing on the proposed Firefox 5+ development plan[1] as Firefox 4 was developed under a different system and has different needs.
---
To reduce version confusion and be explicitly clear the updates will be referred to by codenames. There will be no debate about choices like 4.1 vs 4.0.1 or confusion about the content or schedules. Additionally, the update order maps to codename alphabetical order so you can easily see which comes first just by looking at the codename.
"Anteater"[2] update
---------------------------------------------
* An optional update we will do if late-breaking issues arrive with the Firefox 4 launch and an update needs to be turned around in less than two weeks
* This update may not be needed, but we don't want to be caught flat-footed if it is
* We typically refer to updates of this type as chemspills
"Macaw" update
---------------------------------------------
* Regularly scheduled update
* Slated to come out 2-3 weeks after Firefox 4 (or Anteater if it is indeed needed)
* Small update with a schedule set in stone
* Will only include very bad issues that aren't chemspill worthy and issues preventing us from turning on the advertised update prompt
The advertised update prompt will come after Macaw(2-4 weeks after Firefox 4). This allows us to put any bugs blocking the prompt into Macaw.
If deemed necessary by branch drivers, subsequent releases will use similarily inspired names (Parrot, Puma, etc) and their schedules will be communicated.
Bug and repo mechanics
---------------------------------------------
* These updates will be built out of the releases/mozilla-2.0 repository[3] but fixes will need to be double landed on mozilla-central as well. It is a known issue that we currently don't have nightly testers on releases/mozilla-2.0 and will be dealing with that separately
* Bugs currently marked as blocking2.0: .x+[4] will be targeted for Macaw of future updates, NOT Anteater
* The bugs marked as blocking2.0: .x+ will be retriaged using information from SUMO and Input after the launch and will be judged against stability branch release criteria[5]
* I expect the .x triage and approvals will will begin next week
* It is undecided if fixes taken after Firefox 4 Desktop for Firefox 4 Mobile will also be released in these releases. Due to the branching/repository structure we have options and don't need to make that determination at this time
Please let me know if you have any questions.
Thanks,
Christian
[1] - http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/7054541e967c1bd7
[2] - Keeping with the theme of http://www.mozilla.org/parks/tumucumaque/
[3] - http://hg.mozilla.org/releases/mozilla-2.0/
[4] - https://bugzilla.mozilla.org/buglist.cgi?quicksearch=blocking2.0%3A.x
[5] - https://wiki.mozilla.org/Tree_Rules
John O'Duinn
1) In case people find it useful, the branch diagram for all this can be
found at:
http://oduinn.com/images/2011/blog_branching_for_firefox40_fennec40_3.jpg
2) We're still working out mechanics for nightlies in all of this. For
now, it is intentional that:
* on mozilla-central, we generate nightlies called "4.0b13pre"
* on mozilla-2.0 & mozilla-2.1, we do not yet generate nightlies
Stay tuned.
tc
John.
=====
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
Daniel Veditz
> 1) In case people find it useful, the branch diagram for all this can be
> found at:
> http://oduinn.com/images/2011/blog_branching_for_firefox40_fennec40_3.jpg
>
From the diagram mozilla-2.0 is desktop 4.0.x and mozilla-2.1 is
mobile 4.0.x? Any security fixes have to land on m-c plus two branches?
-Dan
Daniel Veditz
> found at:
> http://oduinn.com/images/2011/blog_branching_for_firefox40_fennec40_3.jpg
>
>From the diagram mozilla-2.0 is desktop 4.0.x and mozilla-2.1 is
John O'Duinn
On 3/20/11 7:59 PM, Daniel Veditz wrote:
> On 3/17/11 4:11 PM, John O'Duinn wrote:
>> 1) In case people find it useful, the branch diagram for all this can be
>> found at:
>> http://oduinn.com/images/2011/blog_branching_for_firefox40_fennec40_3.jpg
>>
>> * on mozilla-2.0 & mozilla-2.1, we do not yet generate nightlies
>
> From the diagram mozilla-2.0 is desktop 4.0.x and mozilla-2.1 is
> mobile 4.0.x?
Yes.
> Any security fixes have to land on m-c plus two branches?
Yes, if the security fix is needed in Firefox4.0.x and also in
Fennec4.0.x, it does need to be landed in mozilla-2.0 and also mozilla-2.1.
While we all agree this is suboptimal, it was the best way we could
avoid disrupting the Firefox4.0RC builds, while still also landing some
last-minute-fennec-blockers into a stable version of mozilla-central for
Fennec4.0RC builds.
> -Dan
tc
John.
=====
John O'Duinn
Mechanically, one thing we think we've nailed down is some version
numbers for nightlies:
a) In the repo releases/mozilla-2.0, nightlies will use version
2.0.1pre/4.0.1pre. This is where any Firefox4.0.x releases will be
generated from.
b) In the repo releases/mozilla-2.1, nightlies will use version
2.1.1pre/4.0.1pre. This is where any Fennec4.0.x releases will be
generated from.
c) In the repo mozilla-central, we are already generating nightlies on
m-c, but these are currently named 2.0b13pre/4.0b13pre. These nightlies
will soon change to use version 2.2a1pre/4.2a1pre. This is where most
other repos/project branches will pull from, and where Firefox.Next
development work will eventually land. ((Reminder: because we cannot
easily downgrade nightly users, for now we're numbering these the lowest
valid number available - as we get closer to release, we can start
calling these 5.0a1pre, as appropriate).
d) We're intentionally not generating nightlies on (a) or (b) yet. We
dont want to change these until after Firefox4.0/Fennec4.0 RCs are
officially shipped, (just in case of any last minute surprises) and
until we resolve some mechanical questions about migrating users across
these branches. Fixing the version number of nightlies on
mozilla-central needs to be coordinated with turning on nightlies for
(a) and (b). We'll make sure to communicate widely before doing all this.
Hope all that helps - let me know if there are any questions. And thanks
for the patience as we track down all the loose ends here.
John.
=====
On 3/17/11 4:11 PM, John O'Duinn wrote:
> Great note, legneato, thanks for sending that.
>
>
> 1) In case people find it useful, the branch diagram for all this can be
> found at:
> http://oduinn.com/images/2011/blog_branching_for_firefox40_fennec40_3.jpg
>
> 2) We're still working out mechanics for nightlies in all of this. For
> now, it is intentional that:
> * on mozilla-central, we generate nightlies called "4.0b13pre"
> * on mozilla-2.0 & mozilla-2.1, we do not yet generate nightlies
Justin Wood (Callek)
In my case, I would love if we could bump milestone.txt prior to the
firefox version.txt. [as in asap]
It is my understanding that the milestone is not used for automation in
the sense of nightly updates, addon updates, etc. Unless the main app
version doesn't have a value.
The use-case for me is allowing comm-central [and our apps] to
differentiate between building from mozilla-2.0 and mozilla-central
which have already diverged enough that the differences have a chance of
mattering.
--
~Justin Wood (Callek)
Mark Banner
>> d) We're intentionally not generating nightlies on (a) or (b) yet. We
>> dont want to change these until after Firefox4.0/Fennec4.0 RCs are
>> officially shipped, (just in case of any last minute surprises) and
>> until we resolve some mechanical questions about migrating users across
>> these branches. Fixing the version number of nightlies on
>> mozilla-central needs to be coordinated with turning on nightlies for
>> (a) and (b). We'll make sure to communicate widely before doing all this.
>
> In my case, I would love if we could bump milestone.txt prior to the
> firefox version.txt. [as in asap]
I agree with this. I suspect this is already known and clear, but I
would say that even if the version number change gets delayed, it must
be changed before mozilla-central is re-opened.
I'd be reasonably happy with not changing until just before re-opening
for Thunderbird, as long as it happens, within the next couple of weeks,
and we get a day or so in-between the two (version number change, tree
reopening) happening so we can adapt our systems.
Standard8