All,

I've posted a draft for an update to the Firefox Release Roadmap
(http://wiki.mozilla.org/ReleaseRoadmap) that includes current
thinking on which product releases will be based upon which platform
branches and how we will transition to Mozilla 2.

Please note that this roadmap is intended as a conceptual view only,
to show the projected relationship and relative timing of product and
pratform releases along with we'll manage respective lifecycles. A
much more detailed technical roadmap with branch mechanics will follow
shortly. Timing of releases and branch points are also TBD.

In particular, this update adds:

* A phased transition to Mozilla 2 starting mid-2007 with end-of-life
and sunset of Gecko 1.x trunk and branches aligned with support
lifecycle, i.e. Gecko 1.9 branch supported up to 6 months following
general availability of the current product release based upon that
branch.

* Firefox 3.5[1] release off of the Gecko 1.9 branch as a front-end
feature oriented release.

* Firefox 4 planned as the first product release off of the Mozilla 2
platform.

The current draft of this roadmap update is posted at:
http://people.mozilla.com/~cbeard/roadmap/

Within the week we hope to revise and finalize this roadmap as
appropriate, to update the currently out-of-date version on the Wiki.

Comments to mozilla.dev.planning.

/cbeard

[1] The actual version number that will be used will determined in due
course for both Firefox 3.5 and Firefox 4. We've been inconsistent in
the past in our versioning and this is something we'll want to revisit.

And on the seventh day christopher.be...@gmail.com spoke:

I cannot seem to grasp the meaning of this paragraph. It would be great
if you could help me out.

1. The 1.9 branch will be EOL'ed 6 months after Firefox 3 comes out.
2. The 1.9 branch will be EOL'ed 6 months after Firefox 3.5 comes out.
3. The 1.9 branch will be EOL'ed 6 months after Firefox 4 comes out.

What is correct? 1, 2 or 3?

Simon
--
Calendar l10n coordinator
Calendar Website Maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog:     http://weblogs.mozillazine.org/calendar

I believe the diagram is clearer than the paragraph, but this is my
understanding:

The 1.8.1 branch will be EOL 6 months after Firefox 3 comes out.
The 1.9.0 branch will be EOL 6 months after Firefox "3.5" comes out.
The 1.9.1 branch will be EOL 6 months after Firefox "4" comes out.

--BDS

You convinced me and mconnor a while back that we should stick with serial
versions. I believe that we should just call this release "Firefox 4" and
call the next release (based on Mozilla2) "Firefox 5".

--BDS

On Jul 2, 10:55 am, Benjamin Smedberg <benja...@smedbergs.us> wrote:

Yes, I believe this is correct.  I've updated the roadmap to help
clarify.

"Transition to Mozilla 2 starting mid-2007 with Gecko branches
supported for six months following subsequent major releases. e.g.
1.8.1 will be supported for 6 months following the release of 1.9.0,
1.9.0 will be supported for 6 months following the release of 1.9.1,
etc."

http://people.mozilla.com/~cbeard/roadmap/

/cbeard

This still gets fuzzy in terms of whether we'll support branches for
longer if apps are still using them within the six month window.  i.e.
Thunderbird 2 was released this spring, so we're still supporting 1.8.0
for Thunderbird, f.e.    I think we need to figure out a way of
addressing extended lifecycles in general, as this also applies to the
Linux vendors stuck on 1.5.0.x for a little while longer.

-- Mike

And on the seventh day Mike Connor spoke:

The question of Thunderbird came to my mind, too. If Thunderbird will
continue to lag behind Firefox releases for about 6 months, this will
create serious problems for Thunderbird users, who are not early adopters
of new releases, e.g. because they only want to update once the first
round of stability and security fixes went in.

Those people will be left hanging in the air, because the Gecko branch of
their release will be discontinued right around the time, that a new TB
release comes out.

This is also a problem that extension authors (like the Lightning
extension) face. For example we still support TB 1.5, because TB 2 only
came out 3 months ago.

Simon
--
Calendar l10n coordinator
Calendar Website Maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog:     http://weblogs.mozillazine.org/calendar

On Monday 2007-07-02 15:32 -0000, christopher.be...@gmail.com wrote:

I think we should be encouraging back-end work for this release, at
least in certain areas, such as layout and probably graphics.

Gecko 1.9 was already a very long cycle for these areas, during
which we did a lot of redesign so that it is easier to fix bugs and
add new features in the future.  But, so that we can ship on time,
we're not doing a lot of the bug fixing and feature addition that
these architectural changes were designed to allow.  I think we
should try to do this for Gecko 1.9.1.

In particular (within the area of layout, CSS, and probably graphics
features):

 * I think we should work on fixing longstanding bugs that are
   important to Web authors and on implementing some of the simpler
   new features (Web standards) that are in demand.  From the
   css-related Web authoring mailing lists that I follow, I get the
   sense that some Web authors see us as falling behind on Web
   standards.  This isn't surprising given that we haven't shipped
   any layout engine updates for 2 years.  I think what we have in
   1.9 will help, but it's really not sufficient to catch up to
   other non-IE browsers in a number of areas.

 * I think we should work on adding features that are needed by the
   Firefox UI.  We didn't have time to work on this in 1.9, and I
   think there's a good bit of demand for some new features from the
   Firefox front end.

During the Gecko 1.9 cycle, which was a long cycle for layout and
graphics rearchitecture, a good bit of JS feature work went into
1.8.1.  I think it makes sense to reverse that, since the Gecko 2.0
cycle sounds like it's going to be a long cycle for JavaScript and
DOM rearchitecture, and plan to get a good bit of layout and
graphics feature work into 1.9.1.

-David

--
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

application_pgp-signature_part < 1K Download

I think it makes sense to keep the major version jumps consistent with
Gecko revision jumps. Web authors should be able to guess which two
versions consecutive versions of Firefox use the same Gecko branch
and which two don't.

~fantasai

I agree a lot here. It would be great to get some low hanging fruit in
on the 1.9.1 branch. One thing I'd love to see is some animation APIs on
top of roc's compositor redesign. Though that'd only make sense if the
compositor redesign can be ported to both the 2.0 and 1.9.1 branches.

There's also some DOM related stuff that is probably going to miss the
Firefox 3 release related to offline (parts of bug 371432) which would
be nice to get release before gecko 2.0.

I would also think there are a number of HTML5 features that we could
add by then which would be interesting. Possibly web forms 2.

Of course, all these features only make sense if they can easily be
written for both the 2.0 and 1.9.1 branches without duplicating too much
work. It's been very noticeable on trunk that it gets harder and harder
to port stuff back to the 1.8.x branch the older it gets. I expect the
same thing to be the case for the 1.9.x branch.

/ Jonas

Perhaps you should also get rid of the extra 0 in release versions, and use
e.g. Firefox 3.0.1 instead of 3.0.0.1.
   Peter.

There is a rationale for the four-digit version numbers, but I can never
remember what it is. Perhaps it's time to reconsider whether we could
combine the functions of two of them.

Gerv

I seem to recall:
[major version] . [minor version] . [extension-breaking update] .
[security fixes]

So if the "minor version" part is going by the wayside, I don't see why
the second digit couldn't go away.

The would only be for Firefox version numbers since, I assume, Gecko
versions would keep the four-part format.

Greg

For 1.5.0.*, it was because we wanted to be able to break extension
compat without changing the 1.5 part.  For 2.0.0.* it was because we
didn't clearly communicate.

Its going to be 3.0.* (I was going to post that next week to make sure
its clear).  If we have to move to 3.1.* due to an unavoidable API
compat issue, that's what we'll do.

Right.  There's a distinct possibility that there will be a 1.9.1, so
we'll need to keep four digit numbers for Gecko.

-- Mike