lifecycle policy
philou
I'm currently using version 3.6. I want to stay on 3.6 as long as
possible but I'm not sure how much longer Mozilla will support it. Is
there a lifecycle policy in place for versions. Are there any know End
of Life/Support dates?
best regards,
Philippe
Henri Sivonen
> possible
Why do you want to stay on 3.6 instead of upgrading to the latest version?
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
beltzner
old versions updated until users have had an opportunity to.upgrade, but
does not guarantee that older versions will be supported once a new version
is available.
(In the past, though, Mozilla has kept older versions up to date for much
longer than this)
cheers,
mike
On 17/05/2011 9:09 AM, "Henri Sivonen" <hsiv...@iki.fi> wrote:
>> I'm currently using version 3.6. I want to stay on 3.6 as long as
>> possible
>
> Why do you want to stay on 3.6 instead of upgrading to the latest version?
>
> --
> Henri Sivonen
> hsiv...@iki.fi
> http://hsivonen.iki.fi/
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
philou
thanks for your reply.
In fact, I make spécific dev under 3.6 which don't work on 4.0. I
would like to know how long I have to change all.
Do you think Mozilla with keep version under LTS (long term support)
like Ubuntu for example, since they will launch a new version every 6
month or less (?)
Best regards,
Philippe
Mike Connor
-- Mike
Nicholas Nethercote
>
> In fact, I make spécific dev under 3.6 which don't work on 4.0. I
> would like to know how long I have to change all.
Everyone's being very cautious in this thread to make no promises at
all. But I suspect, based on historical data, that it is likely
(though not guaranteed) that 3.6 will be supported for several months
at least. In particular, we're only just about to stop supporting
3.5, and I haven't heard anything yet about dropping 3.6 support.
Am I completeness off-base here?
philou, with respect to the 3.6-specific development you have done, if
you describe what you've done I'm sure someone could help you
transition your code to 4.0+. (But dev-platform would be a better
place to ask about that.)
Nick
Matt Brubeck
However, as far as I know there is no current policy specifying a specific length of support for Firefox 3.6 or 4. For Firefox 5 and later, the new version will *be* the security update for the previous version, so users will need to stay on the release channel to be supported and receive updates.
1. https://wiki.mozilla.org/index.php?title=ReleaseRoadmap&oldid=168833
Mike Shaver
> Long ago during the Firefox 2.0 cycle, Mozilla's policy was that each major version would be supported for six months after the next major version was released [1].
"up to six months", actually, though as you say we have always (IIRC)
gone a fair bit longer than that.
Mike
Daniel Veditz
> However, as far as I know there is no current policy specifying a
> specific length of support for Firefox 3.6 or 4.
Several people have repeatedly said in public places (newsgroups,
planning meeting, Monday meeting; could not find a blog or wiki
page) that Firefox 5 will be the security update to Firefox 4, and
that there will be no 4.0.2 unless some issue between now and
shipping Fx5 requires a chemspill response.
-Dan Veditz
Asa Dotzler
I think we have three obvious options:
1) Just do what we've done in the past and continue offering updates to
3.6 and 4.0 until we are comfortable with the balance between "as long
as it takes to get most users migrated forward" and "until porting
security fixes back becomes unbearable".
2) Pull all the levers at our disposal, including automatic updates to
new major versions, as quickly as we can and stop back-porting all
security updates.
3) Treat 3.6 users differently from 4.0 users because the jump from 3.6
to 4 is much larger than the jump from 4.0 to 5.0. Keep supporting 3.6
with security updates and increasingly loud prompted updates to our
latest release until that number of users is low enough to make the
updates automatic. Make Firefox 5 an automatic update for Firefox 4 users.
I think 3 is the path we're on right now.
- A
Robert Kaiser
Erm, IIRC, it was "at least six months" - and we probably are somewhat
bound to that earlier promise still for 3.6 - we should not be for 4 or
later, but I think we didn't say that very loudly, even though it's been
our understanding for some time.
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community needs answers to. And most of the time,
I even appreciate irony and fun! :)
Robert Kaiser
> However, as far as I know there is no current policy specifying a specific length of support for Firefox 3.6 or 4.
We never stated a _specific_ length ever, we stated a minimum, and for
3.6 we probably need to follow that one.
Firefox 4 should be treated as a member of the new breed in that regard,
and have 5 as its security update.
Actually, we are prolonging the security support for 4 and later, it's
not just a minimum of six months any more, now it's "forever", just that
the security updates always bring features and a new "version" as well. ;-)
Robert Kaisre
Asa Dotzler
> Mike Shaver schrieb:
>> On Wed, May 18, 2011 at 1:15 PM, Matt Brubeck<mbru...@mozilla.com>
>> wrote:
>>> Long ago during the Firefox 2.0 cycle, Mozilla's policy was that each
>>> major version would be supported for six months after the next major
>>> version was released [1].
>>
>> "up to six months", actually, though as you say we have always (IIRC)
>> gone a fair bit longer than that.
>
> Erm, IIRC, it was "at least six months" - and we probably are somewhat
> bound to that earlier promise still for 3.6
Actually that's wrong. The exact text of our commitment was:
"Last release to be supported with official security/stability updates
no more than six months following general available of current release"
You can find this throughout our old roadmap documents.
But we're so far past 6 months for 3.6 that it's a moot point there.
> we should not be for 4 or later, but I think we didn't say that
We've been saying it pretty loudly since before 4 shipped. I'm not going
to worry too much there.
- A
Asa Dotzler
> Matt Brubeck schrieb:
>> However, as far as I know there is no current policy specifying a
>> specific length of support for Firefox 3.6 or 4.
>
> We never stated a _specific_ length ever, we stated a minimum
As I said in my earlier comment, that is incorrect. We stated a maximum
-- one that we've regularly ignored for the last few years in favor of
trying to keep users on a secure version of Firefox.
- A
John Thomsen
> On 5/18/2011 2:00 PM, Robert Kaiser wrote:
>> Erm, IIRC, it was "at least six months" - and we probably are somewhat
>> bound to that earlier promise still for 3.6
>
> Actually that's wrong. The exact text of our commitment was:
>
> "Last release to be supported with official security/stability updates
> no more than six months following general available of current release"
>
> You can find this throughout our old roadmap documents.
Okay.
It is also possible to find the opposite statement. According to [1]
talking about Firefox 3:
"our policy is that there's a minimum of 6 months support after n+1
version is out"
However, it doesn't really matter, because it is hard to gracefully kill
these old major versions within 6 months anyway.
> But we're so far past 6 months for 3.6 that it's a moot point there.
You're thinking of 3.5 not 3.6, I believe. See list below compiled from
release notes and other notes:
FF 1.0 had updates for about 6 months after 1.5
FF 1.5 had updates for about 7 months after 2.0
FF 2.0 had updates for about 6 months after 3.0
FF 3.0 had updates for about 9 months after 3.5
FF 3.5 is still alive 16 months after 3.6
FF 3.6 is still alive 2 months after 4.0
FF 4.0 will be unsupported the moment FF 5.0 is released
FF 5.0 will be unsupported the moment FF 6.0 is released
FF 6.0 will be unsupported the moment FF 7.0 is released
...
Regards,
John
Asa Dotzler
> On 2011-05-18 23:26, Asa Dotzler wrote:
>> On 5/18/2011 2:00 PM, Robert Kaiser wrote:
>>> Erm, IIRC, it was "at least six months" - and we probably are somewhat
>>> bound to that earlier promise still for 3.6
>>
>> Actually that's wrong. The exact text of our commitment was:
>>
>> "Last release to be supported with official security/stability updates
>> no more than six months following general available of current release"
>>
>> You can find this throughout our old roadmap documents.
>
> Okay.
>
> It is also possible to find the opposite statement. According to [1]
> talking about Firefox 3:
>
> "our policy is that there's a minimum of 6 months support after n+1
> version is out"
That's a mis-statement of our policy in a page of meeting notes. Sure
you can find all kinds of wrong information if you go digging for it.
The policy is a maximum of 6 months and it has been for years.
>
>> But we're so far past 6 months for 3.6 that it's a moot point there.
>
> You're thinking of 3.5 not 3.6, I believe.
Yes, I was confusing 3.6 and 3.6. Sorry about that. 3.6 will be getting
at least one more security and stability update at approximately the
same time as Firefox 5 is released.
- A
Daniel Cater
Easily done!
Robert Kaiser
> On 2011-05-18 23:26, Asa Dotzler wrote:
>> On 5/18/2011 2:00 PM, Robert Kaiser wrote:
>>> Erm, IIRC, it was "at least six months" - and we probably are somewhat
>>> bound to that earlier promise still for 3.6
>>
>> Actually that's wrong. The exact text of our commitment was:
>>
>> "Last release to be supported with official security/stability updates
>> no more than six months following general available of current release"
>>
>> You can find this throughout our old roadmap documents.
Interesting, do you have a link for that?
> It is also possible to find the opposite statement. According to [1]
> talking about Firefox 3:
>
> "our policy is that there's a minimum of 6 months support after n+1
> version is out"
That's how I remember it.
Asa Dotzler
> John Thomsen schrieb:
>> On 2011-05-18 23:26, Asa Dotzler wrote:
>>> On 5/18/2011 2:00 PM, Robert Kaiser wrote:
>>>> Erm, IIRC, it was "at least six months" - and we probably are somewhat
>>>> bound to that earlier promise still for 3.6
>>>
>>> Actually that's wrong. The exact text of our commitment was:
>>>
>>> "Last release to be supported with official security/stability updates
>>> no more than six months following general available of current release"
>>>
>>> You can find this throughout our old roadmap documents.
>
> Interesting, do you have a link for that?
http://replay.web.archive.org/20060414183729/http://wiki.mozilla.org/ReleaseRoadmap
This is where we codified our commitment.
The update comment is "Last release to be supported with official
security/stability updates no more than six months following general
available of current release" and the text of the document is "the last
major release at any given time would be supported with security and
stability updates for up to six months following general availability of
the current release."
"no more than" and "for up to" both clearly communicate that 6 months is
the outer boundary, not the minimum.
That's the support commitment we made. There was no update to change the
commitment from a maximum of 6 months to a minimum of 6 months. Any
support longer than 6 months was because we were not satisfied with
leaving that many users behind. But that was not a change in our
commitment, it was us going above and beyond our commitment because we
thought, in particular circumstances, it was the right thing to do.
>> It is also possible to find the opposite statement. According to [1]
>> talking about Firefox 3:
>>
>> "our policy is that there's a minimum of 6 months support after n+1
>> version is out"
>
> That's how I remember it.
It's still wrong :-)
- A
Robert Kaiser
> That's the support commitment we made. There was no update to change the
> commitment from a maximum of 6 months to a minimum of 6 months.
Wow, has been widely published wrongly, then, to the point that a lot of
us believed the wrong version. in the view of that, the new model is
even easier to adopt. ;-)
Alan Baxter
Oh, dear. I've been linking the RapidRelease wiki in the support
group and the forums. Apparently it's out of date or I misunderstood
it. Thank you for your clarification. I'll stop linking to it.
https://wiki.mozilla.org/RapidRelease#4.0.x_and_Previous_Releases_.5Bjoduinn.2C_.5D
>This section clarifies some questions that have come up about the relationship between Firefox 4 and older and Firefox 5.
>
> 5.0 and newer processes will not be "backported" onto 4.0.x and older releases
> there will be 4.0.x releases and chemspill handling
> branch team is taking over for 4.0.1
> there will be 3.6.x and 3.5.x releases and chemspill handling
--
atb12345 at gmail dot com
Asa Dotzler
> Daniel Veditz<dve...@mozilla.com> wrote:
>> On 5/18/11 10:15 AM, Matt Brubeck wrote:
>>> However, as far as I know there is no current policy specifying a
>>> specific length of support for Firefox 3.6 or 4.
>>
>> Several people have repeatedly said in public places (newsgroups,
>> planning meeting, Monday meeting; could not find a blog or wiki
>> page) that Firefox 5 will be the security update to Firefox 4, and
>> that there will be no 4.0.2 unless some issue between now and
>> shipping Fx5 requires a chemspill response.
>
> Oh, dear. I've been linking the RapidRelease wiki in the support
> group and the forums. Apparently it's out of date or I misunderstood
> it. Thank you for your clarification. I'll stop linking to it.
>
> https://wiki.mozilla.org/RapidRelease#4.0.x_and_Previous_Releases_.5Bjoduinn.2C_.5D
Did you read the introduction to that section?
> *Current Discussions*
> This section documents key discussion points and proposals
> that are in progress or need to happen. It also notes
> anything unclear. Where possible, it documents owners who
> need to give input and/or drive the item to conclusion.
So, this is a discussion section, not an authoritative answers section.
That being said, there already has been a 4.0.x release and there may be
another if a critical security issue arises that requires a "chemspill"
unplanned emergency fix. But that would be an *unplanned* emergency
release and not a planned one. The planned security update for Firefox 4
is Firefox 5.
- A
Daniel Veditz
>> shipping Fx5 requires a chemspill response.
>
> Oh, dear. I've been linking the RapidRelease wiki in the support
> group and the forums. Apparently it's out of date or I misunderstood
> it. Thank you for your clarification. I'll stop linking to it.
There has been confusion even among the people who have edited that
wiki page.
>> 5.0 and newer processes will not be "backported" onto 4.0.x and older releases
True enough, 4.0.x releases are built and managed in a different
way. Doesn't say anything about the lifetime.
>> there will be 4.0.x releases and chemspill handling
>> branch team is taking over for 4.0.1
Until we stop supporting 4.0.x
>> there will be 3.6.x and 3.5.x releases and chemspill handling
Until we stop supporting them. We have now for 3.5.x: the most
recent 3.5.19 release was the last planned 3.5.x release. Likewise
4.0.1 was the last planned 4.0.x release. There's always the small
possibility of an unplanned ("chemspill") release.
Alan Baxter
Thank you for the clarification. I'll take it as being authoritative.
Alan Baxter
Thank you for the additional clarification. If Fx 5.0 becomes the
security update for Fx 4.0 like Asa says is planned and contains
security fixes that aren't in Fx 4.0, that seems to suggest that Fx
4.0 becomes insecure and no longer supported. In that case, would its
effective lifetime be over, i.e. it becomes EOL just like Fx 3.0 and
its predecessors?
Christian Legnitto
5.0 will be offered as an automatic update. So, in the sense that 3.6.16 is "EOL" when 3.6.17 comes out, yes.
Christian
Alan Baxter
I think I understand. There won't be any 4.0.x releases after 5.0 is
released, i.e. 4.0.x will no longer be supported and becomes EOL.
Christian Legnitto
Correct. But, this won't be as big of an issue as 3.0 and 3.5. For those, we popped up a window asking people to opt in (major update offer). For 4.0.1 users will need to opt out (minor update offer, like point/security releases). Of course the opt-in method leaves many more people behind.
Henri Sivonen
> Correct. But, this won't be as big of an issue as 3.0 and 3.5. For those, we popped up a window asking people to opt in (major update offer). For 4.0.1 users will need to opt out (minor update offer, like point/security releases). Of course the opt-in method leaves many more people behind.
I thought the plan was to do Chrome-style no-questions-asked updates.
Has the plan changed or did I misunderstand earlier? Or am I
misunderstanding what opt out means now?
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Robert Kaiser
> On Mon, 2011-05-23 at 20:59 -0700, Christian Legnitto wrote:
>> Correct. But, this won't be as big of an issue as 3.0 and 3.5. For those, we popped up a window asking people to opt in (major update offer). For 4.0.1 users will need to opt out (minor update offer, like point/security releases). Of course the opt-in method leaves many more people behind.
>
> I thought the plan was to do Chrome-style no-questions-asked updates.
It is. I think what Christian means with "opt-out" is that you
explicitely need to turn off updates if you don't want to be
automatically shifted from 4 to 5.
Mike Shaver
the policy with beard originally.
It is commonly misunderstood as you have here, though, so something could
have been communicated better for sure.
On May 18, 2011 2:05 PM, "Robert Kaiser" <ka...@kairo.at> wrote:
> Mike Shaver schrieb:
>> On Wed, May 18, 2011 at 1:15 PM, Matt Brubeck<mbru...@mozilla.com>
wrote:
>>> Long ago during the Firefox 2.0 cycle, Mozilla's policy was that each
major version would be supported for six months after the next major version
was released [1].
>>
>> "up to six months", actually, though as you say we have always (IIRC)
>> gone a fair bit longer than that.
>
> Erm, IIRC, it was "at least six months" - and we probably are somewhat
> bound to that earlier promise still for 3.6 - we should not be for 4 or
> later, but I think we didn't say that very loudly, even though it's been
> our understanding for some time.
>
> Robert Kaiser
>
>
> --
> Note that any statements of mine - no matter how passionate - are never
> meant to be offensive but very often as food for thought or possible
> arguments that we as a community needs answers to. And most of the time,
> I even appreciate irony and fun! :)
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
Robert Kaiser
> That's not what the link says (click and read it carefully!), and I drafted
> the policy with beard originally.
Asa cleared that up already and apparently that was a long-carrying
wide-reaching misunderstanding then. In any case, it doesn't change our
policy for the future, I guess, so let's just keep the episode in mind
and try not to have something on that scale come up again. ;-)
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
Kohei Yoshino
If you change the cycle, you should discuss and announce that *before*
the release, or enterprise users get confused :-(
--
Kohei Yoshino
Marketing & WebDev, Mozilla Japan
http://mozilla.jp/
Mike Shaver
<yos...@mozilla-japan.org> wrote:
> I thought Fx4 had the same lifecycle policy as before.
> If you change the cycle, you should discuss and announce that *before*
> the release, or enterprise users get confused :-(
We discussed the update model for after FF4 quite extensively, I think.
Mike
Kohei Yoshino
I thought this was the decision for Fx4:
http://mozilla.github.com/process-releases/draft/development_overview/
> We'll be using existing branch maintenance processes for
> Firefox 4.0.x and Firefox 3.6.x security and stability updates.
Henri Sivonen
> Indeed. Users will also have an option to opt out before applying if some of their add-ons are known to be incompatible with the new version (it checks and hollers if compat issues ate found)
Ouch. That basically gives third party developers the power to keep
users from getting Firefox security fixes.
If the user has incompatible extensions at the time of the update push
and the user opts not to install the update, will the update be
reattempted when the incompatible extensions are updated to be
compatible? Also, it seems particularly bad if anti-virus extensions,
Skype toolbars and stuff of that nature on Windows are allowed to hold
back updates.
Alexander Limi
> On Tue, 2011-05-24 at 07:58 -0700, Christian Legnitto wrote:
> > Indeed. Users will also have an option to opt out before applying if some
> of their add-ons are known to be incompatible with the new version (it
> checks and hollers if compat issues ate found)
>
> Ouch. That basically gives third party developers the power to keep
> users from getting Firefox security fixes.
>
This is my biggest worry as well. I'd rather disable broken add-ons
temporarily until the author has updated them, especially now that we have
started doing automated version compatibility bumps, so the add-ons on AMO
are mostly handled.
Third-party hosted add-ons (like Skype, antivirus, etc) will have to move
faster under this new model, but they will have to anyway. They shouldn't be
able to stop people from having the latest security fixes, IMO. I'm willing
to go with some pain and aggressively protect our users on this to
straighten out our current (somewhat broken) add-ons story. But I'm also
sympathetic to the other sides in this discussion, it's not an easy choice
to make.
--
Alexander Limi · Firefox UX Team · @limi <http://twitter.com/limi> ·
limi.net
Kohei Yoshino
We're preparing the Rapid Release & Lifecycle FAQ for the upcoming Fx5 beta release in our Japanese locale.
Can anyone answer my question... when and why this policy has been changed?
Does this mean Fx4 will be maintained until this December (6 months after the Fx5 release), right?
We've never heard Fx5 = Fx4 EOL; that's a shocking news.
Christian Legnitto
The branch maintenance processes are talking about approving fixes, assorted update channels, bug triage, etc....NOT the support level.
Firefox 5 will be the security update for Firefox 4 and delivered as a minor update.
Thanks,
Christian
Mike Connor
On 2011-05-25, at 9:25 PM, Kohei Yoshino wrote:
> On 11/05/25 11:00, Kohei Yoshino wrote:
>> On 11/05/25 10:44, Mike Shaver wrote:
>>> On Tue, May 24, 2011 at 6:37 PM, Kohei Yoshino
>>> <yos...@mozilla-japan.org> wrote:
>>>> I thought Fx4 had the same lifecycle policy as before.
>>>> If you change the cycle, you should discuss and announce that *before*
>>>> the release, or enterprise users get confused :-(
>>>
>>> We discussed the update model for after FF4 quite extensively, I think.
>>
>> I thought this was the decision for Fx4:
>>
>> http://mozilla.github.com/process-releases/draft/development_overview/
>>> We'll be using existing branch maintenance processes for
>>> Firefox 4.0.x and Firefox 3.6.x security and stability updates.
>
> We're preparing the Rapid Release & Lifecycle FAQ for the upcoming Fx5 beta release in our Japanese locale.
> Can anyone answer my question... when and why this policy has been changed?
> Does this mean Fx4 will be maintained until this December (6 months after the Fx5 release), right?
> We've never heard Fx5 = Fx4 EOL; that's a shocking news.
Hi Kohei,
Just to try to clarify, Fx5 does not automatically mean Fx4 is EOL. As stated, the Fx4 release will follow the old process. However, it's a common misconception that the policy promised a full six months of support past the next release. The actual statement in the previous release roadmap reads as follows [1]:
> Adoption of a consumer focused support lifecycle where only the current plus the last major release at any given time would be supported with security and stability updates for up to six months following general availability of the current release.
The key (and deliberately chosen) wording there is "up to six months" as opposed to "at least six months" meaning we may decide to end support sooner. I do not believe the branch team has made any explicit decisions at this time, but we should avoid making any promises about Firefox 4's EOL date in any official statement at this time.
-- Mike
[1] https://wiki.mozilla.org/ReleaseRoadmap?oldid=168833
Mike Connor
Kohei Yoshino
>
> On May 25, 2011, at 6:25 PM, Kohei Yoshino wrote:
>
>> On 11/05/25 11:00, Kohei Yoshino wrote:
>>> On 11/05/25 10:44, Mike Shaver wrote:
>>>> On Tue, May 24, 2011 at 6:37 PM, Kohei Yoshino
>>>> <yos...@mozilla-japan.org> wrote:
>>>>> I thought Fx4 had the same lifecycle policy as before.
>>>>> If you change the cycle, you should discuss and announce that *before*
>>>>> the release, or enterprise users get confused :-(
>>>>
>>>> We discussed the update model for after FF4 quite extensively, I think.
>>>
>>> I thought this was the decision for Fx4:
>>>
>>> http://mozilla.github.com/process-releases/draft/development_overview/
>>>> We'll be using existing branch maintenance processes for
>>>> Firefox 4.0.x and Firefox 3.6.x security and stability updates.
>>
>> We're preparing the Rapid Release & Lifecycle FAQ for the upcoming Fx5 beta release in our Japanese locale.
>> Can anyone answer my question... when and why this policy has been changed?
>> Does this mean Fx4 will be maintained until this December (6 months after the Fx5 release), right?
>> We've never heard Fx5 = Fx4 EOL; that's a shocking news.
>
>
> Firefox 5 will be the security update for Firefox 4 and delivered as a minor update.
Is that new policy described/documented somewhere?
https://wiki.mozilla.org/RapidRelease also says
> End-of-Life:
> * As part of the faster cadence, FF5.0 automatically EOL's when FF6.0 is released with users getting silent updates.
> * For the previous FF4.0.x, FF3.6.x, FF3.5.x releases, we had different policy in place at the time of release.
> While there were problems with the previous policy, we still need to respect other projects (and the users)
> that still depend on these older code lines.
So the Linux distros and enterprise users might think the Fx4 lifecycle policy is the same as before.
End users (and we) are OK even if there's no more 4.0.x, but *please respect* those projects and enterprises
and please announce such important policy change before the release...
Thank you,
-Kohei
Christian Legnitto
We've been saying it in meetings/calls and in various dev-planning threads FWIW. Honestly, the whole release process is a big unknown and may need to be adjusted after Firefox 5's release (though we hope and don't think it will). Obviously, one of the critical pieces we are watching is how Firefox 5 relates to 4, add-on compatibility, impact on partners, support expectations, dropped platforms, etc.
We most definitely reserve the right to change the plan later due to new information or invalid assumptions but we are currently driving to mark Firefox 4 as unsupported when Firefox 5 comes out. We don't intend to have a large user base on the older version because we are switching to opt-out (minor/unadvertised) rather than opt-in (major/advertised). It is our intention to make Firefox 4 to Firefox 5 as much of a non-event as possible, similar to how 3.6.16 to 3.6.17 is.
We are also discussing handing off older repositories to the community if they wish to continue support (as was done for 3.0). It would definitely be nice to have some real bug/repo policies in place before the actual time comes.
Thanks,
Christian
Asa Dotzler
> On 11/05/26 10:36, Christian Legnitto wrote:
>> Firefox 5 will be the security update for Firefox 4 and delivered as a minor update.
>
And the "before" policy was "up to 6 months" which could be zero days or
180 days or any number between those two. There would be no violation of
the old policy if Firefox 4 was unsupported the day Firefox 5 shipped.
We will do what we think is best for the largest number of our users and
that's what we've always done. Our system won't work for some people --
there have been enterprises and distros who wouldn't adapt to our old
model and there will be some that can't adapt to the new one. I think,
however, it's important to note that there is no violation of our
commitment in this change. We are under no obligation to support older
releases any longer than we deem appropriate and sustainable.
- A
Philip Chee
> We are also discussing handing off older repositories to the community if they wish to continue support (as was done for 3.0). It would definitely be nice to have some real bug/repo policies in place before the actual time comes.
I think the TenFourFox PPC build team would definitely be interested in
this. If the Gecko-2.0 branch becomes community supported it might make
it easier for Cameron to get his private PPC patches into the 2.0 tree
(since MoCo wouldn't care too much about what gets checked in there once
it's handed over).
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
Henri Sivonen
> We are also discussing handing off older repositories to the community if they wish to continue support (as was done for 3.0). It would definitely be nice to have some real bug/repo policies in place before the actual time comes.
What would the community do with the repo and why?
I think it is probably already too late to do this, because we've
proceeded a couple on months without landing security fixes and low-risk
regression fixes onto the Firefox 4 branch.
John O'Duinn
On 5/25/11 7:23 PM, Christian Legnitto wrote:
>
> On May 25, 2011, at 7:00 PM, Kohei Yoshino wrote:
>
>> On 11/05/26 10:36, Christian Legnitto wrote:
>>>
>>> On May 25, 2011, at 6:25 PM, Kohei Yoshino wrote:
>>>
>>>> On 11/05/25 11:00, Kohei Yoshino wrote:
>>>>> On 11/05/25 10:44, Mike Shaver wrote:
>>>>>> On Tue, May 24, 2011 at 6:37 PM, Kohei Yoshino
>>>>>> <yos...@mozilla-japan.org> wrote:
>>>>>>> I thought Fx4 had the same lifecycle policy as before.
>>>>>>> If you change the cycle, you should discuss and announce that *before*
>>>>>>> the release, or enterprise users get confused :-(
>>>>>>
>>>>>> We discussed the update model for after FF4 quite extensively, I think.
>>>>>
>>>>> I thought this was the decision for Fx4:
>>>>>
>>>>> http://mozilla.github.com/process-releases/draft/development_overview/
>>>>>> We'll be using existing branch maintenance processes for
>>>>>> Firefox 4.0.x and Firefox 3.6.x security and stability updates.
>>>>
>>>> We're preparing the Rapid Release & Lifecycle FAQ for the upcoming Fx5 beta release in our Japanese locale.
>>>> Can anyone answer my question... when and why this policy has been changed?
>>>> Does this mean Fx4 will be maintained until this December (6 months after the Fx5 release), right?
>>>> We've never heard Fx5 = Fx4 EOL; that's a shocking news.
>>>
>>> The branch maintenance processes are talking about approving fixes, assorted update channels, bug triage, etc....NOT the support level.
>>>
>>> Firefox 5 will be the security update for Firefox 4 and delivered as a minor update.
>>
>> Is that new policy described/documented somewhere?
>>
>> https://wiki.mozilla.org/RapidRelease also says
>>> End-of-Life:
>>> * As part of the faster cadence, FF5.0 automatically EOL's when FF6.0 is released with users getting silent updates.
>>> * For the previous FF4.0.x, FF3.6.x, FF3.5.x releases, we had different policy in place at the time of release.
>>> While there were problems with the previous policy, we still need to respect other projects (and the users)
>>> that still depend on these older code lines.
>>
>> So the Linux distros and enterprise users might think the Fx4 lifecycle policy is the same as before.
>> End users (and we) are OK even if there's no more 4.0.x, but *please respect* those projects and enterprises
>> and please announce such important policy change before the release...
>
>
> We've been saying it in meetings/calls and in various dev-planning threads FWIW.
I agree the plan of record with faster release cadence is to EOL FF5.0.x
when FF6.0 ships, EOL FF6.0 when FF7.0 ships, etc.
However, I believe the EOL plans for releases shipped before the rapid
release cadence are different. We've got 2 proposals for how to handle
EOL of FF3.5. I've heard some early discussions a while ago, but no
final decision that I am aware of, for how to handle EOL of FF3.6, FF4.0.
Christian, it would be helpful to post your thoughts and/or links to
existing discussions, to keep others in the loop. RelEng for example,
would like to verify that these proposals are mechanically possible
before we all commit to them.
Kohei, sorry for the churn during this transition time. There's a *lot*
going on every week just keeping FF5.0, FF6.0 mechanically on track. If
you see anything that we've dropped or not communicated clearly, please
do raise it. And please keep in mind, while this transition has us all
on our toes, the new faster release cadence will make all our lives (and
our users lives!) (and Firefox!) much better!
tc
John.
=====
> Honestly, the whole release process is a big unknown and may need to be adjusted after Firefox 5's release (though we hope and don't think it will). Obviously, one of the critical pieces we are watching is how Firefox 5 relates to 4, add-on compatibility, impact on partners, support expectations, dropped platforms, etc.
>
> We most definitely reserve the right to change the plan later due to new information or invalid assumptions but we are currently driving to mark Firefox 4 as unsupported when Firefox 5 comes out. We don't intend to have a large user base on the older version because we are switching to opt-out (minor/unadvertised) rather than opt-in (major/advertised). It is our intention to make Firefox 4 to Firefox 5 as much of a non-event as possible, similar to how 3.6.16 to 3.6.17 is.
>
> We are also discussing handing off older repositories to the community if they wish to continue support (as was done for 3.0). It would definitely be nice to have some real bug/repo policies in place before the actual time comes.
>
> Thanks,
> Christian
Robert Kaiser
> It is our intention to make Firefox 4 to Firefox 5 as much of a non-event as possible, similar to how 3.6.16 to 3.6.17 is.
And I think we are on a quite good way to make it that. The biggest
obstacle I'm seeing so far is add-ons that load binaries - we can't
solve that one easily. All the others should be doable, even if we need
more work on all that.