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.
Philip Chee
I believe that Cameron Kaiser is tracking security fixes and I'm fairly
certain that he's been backporting such fixes to his TenFourFox
repository. If the right policies are in place he could push his
changesets to the community repository.
Cameron Kaiser
>
> > 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.
>
> I believe that Cameron Kaiser is tracking security fixes and I'm fairly
> certain that he's been backporting such fixes to his TenFourFox
> repository. If the right policies are in place he could push his
> changesets to the community repository.
I'm always late to these discussions ...
Anyway, yes, I'm continuing development on our internal mozilla-2.0
while we evaluate how amenable Fx5 is to 10.4 PPC (so far we're having
serious problems with the port, unfortunately). TenFourFox 4.0.2 is
due to come out this weekend with security issues I've backported. I
would not mind being effectively the driver for 2.0, but I don't know
who else is out there downstream -- other than SeaMonkey, which if I
understand Philip and Robert correctly will move to Mozilla 5, I think
we're the only ones based on it. Dan Veditz has reenabled the flag for
approval-2.0 and at least one bug has landed post-Macaw under that
basis (I think biesi landed the multiple cookies bug), and that and
others will be in "4.0.2." I've taken pains in the release notes to
remind people this is not based on any official Firefox release.
If we can't get Fx5 on 10.4 PPC, then the next move is to start
backporting high-yield Fx5 features to a TenFourFox "4.1". Some of the
low-hanging fruit and low-risk bug fixes are already slated for our
4.0.3 (pending our crack community hackers taking a whack on the Fx5
build system where I have failed). I suspect this would be
controversial on an official release branch, but if this were kosher
I'd be happy to spearhead and maintain it.
Cameron Kaiser
Jean-Marc Desperrier
> 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).
IMO it would be better to use a model more similar to the one of Ubuntu.
For example : One out of 8 releases (^=one a year) is a LTS release that
*will* get security update and will EOL only after the next LTS release
is out.
Normal users get updated to each new release, but people who need the
stability and don't care about frequent functionality update can stay on
the LTS release for a whole year.
> 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.
There necessarily will be a portion of users for which it won't be a
non-event, it can't stay a non-event for everybody a long time, or it
would mean that this new model slows down functional changes.
Asa Dotzler
> On 26/05/2011 04:23, Christian Legnitto wrote:
>> 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).
>
> IMO it would be better to use a model more similar to the one of Ubuntu.
> For example : One out of 8 releases (^=one a year) is a LTS release that
> *will* get security update and will EOL only after the next LTS release
> is out.
>
> Normal users get updated to each new release, but people who need the
> stability and don't care about frequent functionality update can stay on
> the LTS release for a whole year.
Sounds nice. Are you offering to maintain security and stability updates
for all previous releases between LTS updates? There's no free lunch here.
>> 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.
>
> There necessarily will be a portion of users for which it won't be a
> non-event, it can't stay a non-event for everybody a long time, or it
> would mean that this new model slows down functional changes.
The new model doesn't slow down functional change. Change happens at
about the same rate year to year, but things ship when they're ready
rather than batching them up for long periods.
- A
Daniel Veditz
> On 5/27/2011 4:35 PM, Jean-Marc Desperrier wrote:
>> Normal users get updated to each new release, but people who need the
>> stability and don't care about frequent functionality update can
>> stay on the LTS release for a whole year.
>
> Sounds nice. Are you offering to maintain security and stability
> updates for all previous releases between LTS updates? There's no
> free lunch here.
He's not the one with several hundred million users. We won't know
the effects of the new plan for a while, but if it results in users
smeared across lots of old versions Mozilla might be better off
supporting a more conservative upgrade path in addition to the quick
cycle.
We have no data, it's premature to guess whether we need to do so
until after we release Firefox 6 (yes, 6 -- 5 represents the
transition and likely won't be typical).
You don't fall back to "plan B" until after you've given "plan A" a
chance.
-Dan
Asa Dotzler
> On 5/27/11 4:46 PM, Asa Dotzler wrote:
>> On 5/27/2011 4:35 PM, Jean-Marc Desperrier wrote:
>>> Normal users get updated to each new release, but people who need the
>>> stability and don't care about frequent functionality update can
>>> stay on the LTS release for a whole year.
>>
>> Sounds nice. Are you offering to maintain security and stability
>> updates for all previous releases between LTS updates? There's no
>> free lunch here.
>
> He's not the one with several hundred million users. We won't know
> the effects of the new plan for a while, but if it results in users
> smeared across lots of old versions Mozilla might be better off
> supporting a more conservative upgrade path in addition to the quick
> cycle.
Why would it result in users smeared across versions? If it's an
unprompted update, it should match what we've seen for unprompted
updates in the past -- very solid update rates.
The suggestion that we should maintain security updates for 8 or 9
releases every year is just silly unless he's willing to step up and
offer the resources to do that. That's the whole point of my reply.
- A
Boris Zbarsky
> The suggestion that we should maintain security updates for 8 or 9
> releases every year
That wasn't the suggestion. The suggestion was that there be _one_
release a year that we maintain security updates for.
So say we ship Fx 5 and designate that as the LTS release for this year.
Then we would ship Fx 6, 7, 8, 9, 10, 11, 12, 13, which gets us to
about June 2012. In parallel we would be shipping security updates to
Fx5 _only_ by packporting security fixes from ongoing work to just the
Fx5 relbranch.
Then we designate the Fx 13 or Fx 14 release as the new LTS release,
end-of-life Fx5, and repeat.
I'm not sure this is something we should worry about at this stage; if
it turns out that our new release schedule is really not working for a
large fraction of our users, then we should worry about this. But the
suggestion that was made is much saner than what I think you read it to be.
-Boris
Henri Sivonen
> I'm not sure this is something we should worry about at this stage; if
> it turns out that our new release schedule is really not working for a
> large fraction of our users, then we should worry about this. But the
> suggestion that was made is much saner than what I think you read it to be.
I think we shouldn't worry about this now, but a comment about the LTS
idea:
Ubuntu needs LTS releases, because they break basic stuff in normal
releases. That is, their QA process isn't very good or they don't act on
the output of the QA process well enough. I think the key problem of
Ubuntu is that their release schedule is date-driven but their still do
feature-driven development so they ship broken stuff when the
pre-announced release day comes. Our now process is different in the
sense that features are supposed to be allowed to miss release trains if
they aren't ready.
Our QA process lets regressions slip though, too. However, running a
pre-release version of a browser is much easier that running a
pre-release operation system (on real hardware to see real driver bugs).
So in the Firefox case, unlike it the Ubuntu case, it should be pretty
easy for any organization that relies on Firefox updates not breaking
whatever they want not broken by having a person or two who use Aurora
as their browser within the organization. If we regress something and
it's caught in the Aurora phase, there's still a chance of unregressing
before release or to fix it in their intranet.
(Additionally, we might do better on the regression avoidance front if
we had Opera-style Web feature QA. Opera has QA write test suites from
the spec, which is substantially different to our approach to test
cases.)
On the other hand, people who use IE6, 7 or 8 are basically running LTS
browsers. It's well-known that for Web authors, those browsers are
holding the Web back. I think enabling people (or, rather,
organizations) to run old versions Firefox would also slow down progress
on the Web and, therefore, would not be a good way to implement
Mozilla's mission.
Jesper Kristensen
>> He's not the one with several hundred million users. We won't know
>> the effects of the new plan for a while, but if it results in users
>> smeared across lots of old versions Mozilla might be better off
>> supporting a more conservative upgrade path in addition to the quick
>> cycle.
>
> Why would it result in users smeared across versions? If it's an
> unprompted update, it should match what we've seen for unprompted
> updates in the past -- very solid update rates.
Hopefully, but it is not given. Add-on authors are told to make their
maxVersion x.y.*, so add-ons may become incompatible at every single
unprompted update. From what I have read, updates still require opt-in
if it results in incompatible add-ons. (is this still the plan?) This is
handled for AMO hosted add-ons, but my experience from support forums is
that add-ons not hosted on AMO experience incompatibilities far more
frequently.
I don't think a LTS release is a solution, I just want to say that the
automatic update process is very uncertain.
Jean-Marc Desperrier
>> IMO it would be better to use a model more similar to the one of Ubuntu.
>> For example : One out of 8 releases (^=one a year) is a LTS release that
>> *will* get security update and will EOL only after the next LTS release
>> is out.
>>
>> Normal users get updated to each new release, but people who need the
>> stability and don't care about frequent functionality update can stay on
>> the LTS release for a whole year.
>
> Sounds nice. Are you offering to maintain security and stability updates
> for all previous releases between LTS updates? There's no free lunch here.
In that scenario, there would be only two versions supported in parallel :
- during this year, current version and Fx 5
- during next year, current version and Fx 13, etc.
This is less that what Mozilla was doing until now.
However I perfectly agree that this plan makes sense only if you really
get a strong demand for those LTS versions, if some people really find
the current plan unworkable for them (and can justify why).
Maybe I just missed it but I didn't see what kind of reactions you got
from Linux distributions about the new rapid release schedule ?
They're the primary target that I'd expect to be up in arms over their
need for LTS versions (and to whom you could tell that they *need* to
get involved in the security patch ports for the LTS version or then it
won't happen).
Henri Sivonen
> Maybe I just missed it but I didn't see what kind of reactions you got
> from Linux distributions about the new rapid release schedule ?
> They're the primary target that I'd expect to be up in arms over their
> need for LTS versions (and to whom you could tell that they *need* to
> get involved in the security patch ports for the LTS version or then it
> won't happen).
The "need" of LTS versions for Linux distros is a policy matter that can
be fixed by adjusting distro policies so that LTS versions aren't
"needed".
It's worth noting that Ubuntu already updates Chromium with
features--not just security fixes--at Google's schedule. That is, Ubuntu
puts the latest Chromium in their repos even after a distribution
release has been shipped.
Debian, OTOH, ships an ancient version of Chromium. It would be
interesting to know if users actually want to use the ancient version or
if users who want Chrome/Chromium add a repo that gives them the latest
anyway. After all, the Web that the ancient Chromium is supposed to
interact with moves on assuming that everyone who uses Chrome has the
latest Chrome without caring about Debian sticking to an ancient
Chromium.
Freezing app versions could be considered a bug. See
http://www.omgubuntu.co.uk/2011/05/the-evolution-of-the-personal-package-archive-system/
Georg Maaß
> So say we ship Fx 5 and designate that as the LTS release for this year.
> Then we would ship Fx 6, 7, 8, 9, 10, 11, 12, 13, which gets us to about
> June 2012. In parallel we would be shipping security updates to Fx5
> _only_ by packporting security fixes from ongoing work to just the Fx5
> relbranch.
>
> Then we designate the Fx 13 or Fx 14 release as the new LTS release,
> end-of-life Fx5, and repeat.
This is a model I can live with, because then the LTS is "the real
release" with feature freeze on top of which I can build my
applications, but jumping from fx 5 to 6 to 7 and so on each with
internal differences and possibility of incompatibility, when I update
for desired security fixes only, is like running directly on the daily
nightlies, which is just a nightmare.
Robert Accettura
deployments (while it is a long time in the browser world). Any data
behind the number 12 vs 18 or 24? Would a longer window (strictly
security bug fixes) lead to more deployments?
Georg Maaß
> 12 months seems short to designate LTS for a distros or corporate
> deployments (while it is a long time in the browser world). Any data
> behind the number 12 vs 18 or 24? Would a longer window (strictly
> security bug fixes) lead to more deployments?
36 months would be much better for on top products (especially XULRUnner
apps), because development of on top products like XULRunner apps can
not start before the release has been deployed, so with the rapid
release cycle the on top products will be always more or less
incompatible with the current release or insecure if they ship with an
outdated XULRunner.
For those who decided to introduce that rapid release cycle 12 months
might be a compromise they could agree too.
For XULRunner apps with 1 or two developers only working only weekend
per weekend on the project the rapid release cycle is a nightmare,
because each update may result in an new unexpected incompatibility
instead of just more security.
beltzner
deployments and embedders, I'm not at all certain it's the best thing for
the web or for Mozilla.
What do other web stack vendors do? What's the minimum interval for IE or
Chrome, and what for Trident and Webkit?
My instinct is to let corporate deployers catch up to a faster (remember:
we're talking 12 months) cycle, and to get serious about our embedding
story, which presently seems to be caveat emptor, quite honestly (and
perhaps appropriately). We don't have the resources - as a community - to
focus on their problems and on moving the web forward.
cheers,
mike
On 12/06/2011 12:16 PM, "Georg Maaß" <ge...@bioshop.de> wrote:
azakai
> > released, i.e. 4.0.x will no longer be supported and becomes EOL.
>
> 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.
Is this still the plan? If so, are we not concerned about a 4 to 5
update breaking addons? And of people staying on 4 because 5 doesn't
support their addons, and consequently being on an EOL'ed browser?
(There is a lot of negativity about both issues on Slashdot right now,
with a link to this thread.)
- azakai
Christian Legnitto
It is the plan and it was implemented starting yesterday. There will be a blog post with more details coming out today, I'll reply here when it is done.
Thanks,
Christian
Mike Shaver
> 12 months seems short to designate LTS for a distros or corporate
> deployments (while it is a long time in the browser world). Any data
> behind the number 12 vs 18 or 24? Would a longer window (strictly
> security bug fixes) lead to more deployments?
I would be surprised if even a 60-month LTS window would get us
additional adoption exceeding a week's downloads at our current rate.
Mike
Paul Biggar
> (There is a lot of negativity about both issues on Slashdot right now,
> with a link to this thread.)
This concerns me. I've seen exactly the same negativity anywhere
Firefox 5 or the new release schedule is mentioned (HackerNews
primarily, and other early adopter sites). My impression is that the
people who have legitimate cause for concern are:
- addons users: Does FF5 cause addons to fail for a majority of users?
It certainly seems that way from complaints. I thought we fixed this,
but maybe not early enough in the cycle?
- sysadmins: I know nothing about corporate deployments, etc. I've not
heard this discussed in the rapid release plans. Do we have plans to
ease their burdens?
There is a lot of complaints about the version numbers, which seems to
be one of those issues that people get caught up in even though it's
irrelevant. I don't have any idea how we'd overcome this.
--
Paul Biggar
Compiler Geek
pbi...@mozilla.com
@paulbiggar
Boris Zbarsky
> - addons users: Does FF5 cause addons to fail for a majority of users?
> It certainly seems that way from complaints. I thought we fixed this,
> but maybe not early enough in the cycle?
It causes addons to fail for a majority of the users who're complaining? ;)
Seriously, most of the complaints I've seen seem to focus on custom
non-AMO addons that people have to interface with intranet junk of
various sorts....
> - sysadmins: I know nothing about corporate deployments, etc. I've not
> heard this discussed in the rapid release plans.
It was discussed, and some of that discussion was even quoted in the
press. I believe the relevant quote was something along the lines of
not having the resources to solve the problems corporate deployment is
facing while continuing to move the web forward.
> There is a lot of complaints about the version numbers, which seems to
> be one of those issues that people get caught up in even though it's
> irrelevant. I don't have any idea how we'd overcome this.
There's a fair number of people also pointing out that it's irrelevant,
except insofar as it affects addon compat.
One way to overcome this if we really cared is to name the next release
Firefox 2011-08-16....
-Boris
beltzner
> This concerns me. I've seen exactly the same negativity anywhere
> Firefox 5 or the new release schedule is mentioned (HackerNews
> primarily, and other early adopter sites).
We should also be sure to index/take stock of the number of *positive*
mentions and feedback on the rapid release cycle. I have seen a great
deal of positive reaction in technology news sites, and perhaps more
importantly, from web developers and designers who are building new
technologies.
The positive feedback seems to emphasize:
- moving the hundreds of millions of Firefox users onto a more modern
and capable set of web technologies
- providing more power for web application developers
- ensuring that Firefox users are always getting the best speed
possible out of modern web pages
- keeping people more secure with the latest developed code
> - addons users: Does FF5 cause addons to fail for a majority of users?
> It certainly seems that way from complaints. I thought we fixed this,
> but maybe not early enough in the cycle?
Quite a valid concern, and I was happy to discover that wherever
possible, compatibility was automatically bumped for add-ons that were
not affected by the code delta from Firefox 4 to Firefox 5. I know
that there are more plans to improve this automation, better control
those deltas to ensure that we're balancing between changes required
for improvements to Firefox and those which will affect legacy
add-ons, and aggressive build out of the Add-On SDK which is designed
with forward-compatibility in mind.
Add-ons have often been the reason why Firefox milestones were so far
apart, and why Mozilla was unable to ship technology to users as
quickly as it would have liked. I think it will be a painful hill for
us to climb as a community, and yes, we should expect a good deal of
negative feedback as we make the change. While by no means should it
be ignored, we should make sure that we're not over rotating towards
it.
At the end of the day this will be a difference of opinion and
approach which has very hard costs and benefits to quantify. For
example: what do we give up by supporting legacy Add-ons? how many
users will we lose forever by dropping that support, and what is the
overall cost to our ability to execute against our mission?
> - sysadmins: I know nothing about corporate deployments, etc. I've not
> heard this discussed in the rapid release plans. Do we have plans to
> ease their burdens?
Mozilla has never really had a good answer for these users. Even the
existing release process wasn't considered sufficient (MSI support was
required, system group policy support was required) so I do feel it
important to point out that these criticisms aren't exactly new.
That said, it's always been possible to override the update server
used, and corporate deployments can continue to do that if they want
to first vet the updates.
> There is a lot of complaints about the version numbers, which seems to
> be one of those issues that people get caught up in even though it's
> irrelevant. I don't have any idea how we'd overcome this.
In this case, I actually think the only answer is to just be bold and
let it hang. Version numbers really shouldn't have any meaning to
users. They should be able to know they are running a product, and
have the latest version, or the preview version, or whatever. Website
development models have led and shown us the way, here.
cheers,
mike
Paul Biggar
> Add-ons have often been the reason why Firefox milestones were so far
> apart, and why Mozilla was unable to ship technology to users as
> quickly as it would have liked. I think it will be a painful hill for
> us to climb as a community, and yes, we should expect a good deal of
> negative feedback as we make the change. While by no means should it
> be ignored, we should make sure that we're not over rotating towards
> it.
Also, I'd love to know how Chrome manages to do so well here (assuming
that they do, in fact, do well).
beltzner
> Also, I'd love to know how Chrome manages to do so well here (assuming
> that they do, in fact, do well).
>From my observation, a combination of never having set a different
expectation and not really giving a toss, as well as always having a
forward-compatible customization model.
They've also done some things for corporate deployments (MSI & group
policy, for example) but not for a second given the impression that
they'd slow down the release cadence.
cheers,
mike
Daniel Veditz
> On 6/22/11 4:08 PM, Paul Biggar wrote:
>> There is a lot of complaints about the version numbers, which
>> seems to be one of those issues that people get caught up in
>
> irrelevant, except insofar as it affects addon compat.
Had we called it "4.1" some of those people might have been happier
(it's a small, incremental, change) but we'd have exactly the same
addon compatibility issues which is a far more legitimate complaint.
> One way to overcome this if we really cared is to name the next
> release Firefox 2011-08-16....
I thought they were all called "Gecko/20100101" now :-)
-Dan Veditz
Boris Zbarsky
> Also, I'd love to know how Chrome manages to do so well here (assuming
> that they do, in fact, do well).
If you mean in terms of extension compat, Chrome extensions are written
to a specific extension API that abstracts away the core code, so they
can make core changes without changing extension APIs. On the flip
side, the extension API is less powerful than full-on Firefox
extensions. Pretty similar setup to what we're aiming for with the
addon SDK, actually.
-Boris
David E. Ross
>
> We should also be sure to index/take stock of the number of *positive*
> mentions and feedback on the rapid release cycle. I have seen a great
> deal of positive reaction in technology news sites, and perhaps more
> importantly, from web developers and designers who are building new
> technologies.
>
> The positive feedback seems to emphasize:
> - moving the hundreds of millions of Firefox users onto a more modern
> and capable set of web technologies
> - providing more power for web application developers
> - ensuring that Firefox users are always getting the best speed
> possible out of modern web pages
> - keeping people more secure with the latest developed code
>
If the move from Firefox 4 to Firefox 5 is indeed related to the first
two of those points, this new versioning scheme can be understood. A
number of users who don't follow this discussion will infer from
changing the version number from 4 to 5 that a major set of enhancements
has been implemented, which is what those two points (and possibly the
third point) describe.
However, I was under the impression that this move was merely a security
update. If that is true, changing the version from 4 to 5 thus misleads
the public as to the significance of the update.
--
David E. Ross
<http://www.rossde.com/>
On occasion, I might filter and ignore all newsgroup messages
posted through GoogleGroups via Google's G2/1.0 user agent
because of spam from that source.
Jesper Kristensen
>> - addons users: Does FF5 cause addons to fail for a majority of users?
>> > It certainly seems that way from complaints. I thought we fixed this,
>> > but maybe not early enough in the cycle?
> Quite a valid concern, and I was happy to discover that wherever
> possible, compatibility was automatically bumped for add-ons that were
> not affected by the code delta from Firefox 4 to Firefox 5. I know
> that there are more plans to improve this automation, better control
> those deltas to ensure that we're balancing between changes required
> for improvements to Firefox and those which will affect legacy
> add-ons, and aggressive build out of the Add-On SDK which is designed
> with forward-compatibility in mind.
What kind of outreach to addon developers is Mozilla doing on addon
compatibility? I have been asked by a handful of people today where they
can download Firefox 4, and I really don't want to just tell. If I could
promise that their favorite Google Toolbar or McAfee SiteAdvisor addons
would be made compatible within day, I would just do that, but I don't
know what the timeline is for these addon vendors. Does anybody know?
Asa Dotzler
> Den 22-06-2011 22:32, beltzner skrev:
>>> - addons users: Does FF5 cause addons to fail for a majority of users?
>>> > It certainly seems that way from complaints. I thought we fixed this,
>>> > but maybe not early enough in the cycle?
>> Quite a valid concern, and I was happy to discover that wherever
>> possible, compatibility was automatically bumped for add-ons that were
>> not affected by the code delta from Firefox 4 to Firefox 5. I know
>> that there are more plans to improve this automation, better control
>> those deltas to ensure that we're balancing between changes required
>> for improvements to Firefox and those which will affect legacy
>> add-ons, and aggressive build out of the Add-On SDK which is designed
>> with forward-compatibility in mind.
>
> What kind of outreach to addon developers is Mozilla doing on addon
> compatibility?
As much as we possibly can. Seriously.
- A
Rick Alther
> 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.
>
a dead horse here, but I have serious concerns over this new versioning
policy.
First, let me state that I'm all for the quicker release cycles. Get
the features, fixes and enhancements to the users sooner.
However, I'm not a fan of 5.0 being a minor update to 4.0. Why not just
label it 4.1.0 or something similar then? How are we supposed to know
when a new release is a major update or not? 4.0 -> 5.0 seems major to
me looking at the version number. Personally, I feel a little short
changed getting a "major" release and it's really just a couple of
enhancements and fixes. What happens if there is a change which changes
the ABI/API significantly to break stuff (as a major version might)?
The extensions argument, of course, has been discussed and I know you
plan on some sort of automated method of updating compatible extensions
automatically on AMO. However, what about extensions not hosted on AMO,
in particular, internal enterprise repositories?
This new versioning policy really hinders enterprise uptake.
Enterprises have to do lots of testing to ensure internal apps are
compatible. With minor updates, it's not much of an issue because that
implies nothing significant changed - just fixes and perhaps minor
enhancements. Major releases require testing. Even though 5.0 is a
minor update to 4.0, it's not presented that way and app owners and help
desk support just see it as a major release. That's one primary reason
Chrome is not in enterprises (as a default browser). It's why Firefox
is being adopted (IBM for instance). Faster releases don't break the
enterprise, but a versioning policy where you can't tell what's major
and what's minor does.
Finally, EOLing a product that is merely weeks old (4.0) will also scare
off enterprises. An enterprise needs to standardize on a release for at
least a few months before later versions are tested and approved. If
they can't be sure that it will be supported with at least security
updates, Firefox will loose traction in the enterprise.
Firefox is a great product and the fact that enterprises have been
adopting it as their standard, supported browser says a lot. I feel
that this policy will quickly cause Firefox to be dropped from enterprises.
For your home users, this current policy likely has little impact
(except perhaps extensions) and will work well, but it's very poor for
enterprises.
Thanks,
- Rick Alther
Joshua Cranmer
> However, I'm not a fan of 5.0 being a minor update to 4.0. Why not
> just label it 4.1.0 or something similar then? How are we supposed to
> know when a new release is a major update or not? 4.0 -> 5.0 seems
> major to me looking at the version number. Personally, I feel a
> little short changed getting a "major" release and it's really just a
> couple of enhancements and fixes. What happens if there is a change
> which changes the ABI/API significantly to break stuff (as a major
> version might)?
guarantees, with the possible exception of jetpack stuff. In essence,
every release cycle is in theory a major release, and, judging by the
amount of comm-central breakage that happens, every release will be a
major release in that regard.
> Finally, EOLing a product that is merely weeks old (4.0) will also
> scare off enterprises. An enterprise needs to standardize on a
> release for at least a few months before later versions are tested and
> approved. If they can't be sure that it will be supported with at
> least security updates, Firefox will loose traction in the enterprise.
you about 12 weeks (3 months) of testing before the release.
Paul Biggar
On Wed, Jun 22, 2011 at 16:36, Rick Alther <alt...@acm.org> wrote:
> However, I'm not a fan of 5.0 being a minor update to 4.0. Why not just
> label it 4.1.0 or something similar then? How are we supposed to know when
> a new release is a major update or not? 4.0 -> 5.0 seems major to me
> looking at the version number. Personally, I feel a little short changed
> getting a "major" release and it's really just a couple of enhancements and
> fixes. What happens if there is a change which changes the ABI/API
> significantly to break stuff (as a major version might)?
This change is really just a different way to look at version numbers.
We no longer think of version numbers in terms of ABI/API changes, nor
of major/minor features. In fact, we'd love it if version numbers just
went away, but we need them for bug reports.
If version numbers are important to you, please think of this as
Firefox version 4.1. If you're in enterprise, this release has as much
risk as version 4.1 would.
> Finally, EOLing a product that is merely weeks old (4.0) will also scare off enterprises
Actually, we EOLed 4.0 a few weeks ago in favour of 4.0.1. Now we're
EOLing 4.0.1 in favour of 4.1^H^H^H5.0. There's nothing new or scary
here.
I hope this helps with your concerns,
Paul
JR Conlin
As someone who has come from a few enterprise operations, may I
contribute a thought?
Testing a package usually requires about a week of dedicated time from
an individual who runs against a set checklist of operations. Since
these individuals don't generally contribute to "bottom line costs"
there's often not a lot of them, or they have to split their time doing
other, higher value forms of support/ tasks/ watering the plants/ etc.
Enterprises usually have more than one set of tools. This means that as
new tools version, they have to be scheduled into the limited amount to
be reviewed and qualified, with documentation updates, etc since a one
week review may take several weeks to complete.
Not everyone has the same time scale.
Mike Hommey
> Hi Rick,
>
> On Wed, Jun 22, 2011 at 16:36, Rick Alther <alt...@acm.org> wrote:
> > label it 4.1.0 or something similar then? ï¿œHow are we supposed to know when
> > a new release is a major update or not? ￜ4.0 -> 5.0 seems major to me
> > looking at the version number. ï¿œPersonally, I feel a little short changed
> > getting a "major" release and it's really just a couple of enhancements and
> > significantly to break stuff (as a major version might)?
>
> We no longer think of version numbers in terms of ABI/API changes, nor
> of major/minor features. In fact, we'd love it if version numbers just
> went away, but we need them for bug reports.
>
> If version numbers are important to you, please think of this as
> Firefox version 4.1. If you're in enterprise, this release has as much
> risk as version 4.1 would.
If we change the significance of the version numbers, it might be
clearer to use a completely different version number scheme, which
doesn't imply anything wrt the relationship with versions before the
introduction of the new scheme. This has been mentioned several times,
but date based versions could provide that.
Mike
Mike Hommey
> On 6/22/2011 4:49 PM, Joshua Cranmer wrote:
> contribute a thought?
>
> Testing a package usually requires about a week of dedicated time
> from an individual who runs against a set checklist of operations.
> Since these individuals don't generally contribute to "bottom line
> costs" there's often not a lot of them, or they have to split their
> time doing other, higher value forms of support/ tasks/ watering the
> plants/ etc. Enterprises usually have more than one set of tools.
> This means that as new tools version, they have to be scheduled into
> the limited amount to be reviewed and qualified, with documentation
> updates, etc since a one week review may take several weeks to
> complete.
>
> Not everyone has the same time scale.
And not everyone can start the process every six weeks, which taking the
train on mozilla-aurora doesn't change: we may be ahead of time for a
given release, but next train will still be 6 weeks from then.
Mike
Nicholas Nethercote
>
> If version numbers are important to you, please think of this as
> Firefox version 4.1. If you're in enterprise, this release has as much
> risk as version 4.1 would.
I really wish we'd gone with 4.1, 4.2, ..., 4.9, 5.0, 5.1, ..., 5.9,
6.0. It would appease the people who are annoyed by the big version
numbers, would have been more consistent with the old approach, and
would look less like Chrome. Ah well.
N
ps: Date-based versioning is awful, BTW. (Assuming you release more
often than once per year.) We used it with Valgrind for a while years
ago, everyone hated it.
Daniel Veditz
> However, I was under the impression that this move was merely a security
> update. If that is true, changing the version from 4 to 5 thus misleads
> the public as to the significance of the update.
No, not "merely" a security update. If it were we would have called
it "4.0.2"
http://www.mozilla.com/en-US/firefox/5.0/releasenotes/#whatsnew2
-Dan Veditz
Alexander Limi
> - addons users: Does FF5 cause addons to fail for a majority of users?
> It certainly seems that way from complaints. I thought we fixed this,
> but maybe not early enough in the cycle?
>
The main issue “in the field” is that a large part of the add-ons aren't on
AMO, and can't be automatically version-bumped — which I believe was done
early enough in the cycle for those that are. Mozilla did what they could,
but companies are often not particularly responsive about these things.
Add-ons like Google Toolbar, antivirus toolbars and other third-party
add-ons (…that users very often have no idea that they even installed, see
the Skype debacle) will have to make sure they test and update their
add-ons. Mozilla has automated ways to do this for add-ons hosted on
addons.mozilla.org, but if you install an add-on from a third-party source,
they will have to handle their own updates.
--
Alexander Limi · Firefox UX Team · @limi <http://twitter.com/limi> ·
limi.net
Rick Alther
>> Finally, EOLing a product that is merely weeks old (4.0) will also scare off enterprises
>
> Actually, we EOLed 4.0 a few weeks ago in favour of 4.0.1. Now we're
> EOLing 4.0.1 in favour of 4.1^H^H^H5.0. There's nothing new or scary
> here.
3.6 refers to the entire 3.6 series of releases.
> I hope this helps with your concerns,
Sadly, no :-(
Boris Zbarsky
> However, I'm not a fan of 5.0 being a minor update to 4.0. Why not just
> label it 4.1.0 or something similar then? How are we supposed to know
> when a new release is a major update or not?
How are you defining "major update"?
> What happens if there is a change which changes
> the ABI/API significantly to break stuff (as a major version might)?
5.0 breaks ABI in various ways. Binary addons that are compatible with
4.0 are not compatible with 5.0 without recompiling, generally.
> However, what about extensions not hosted on AMO,
> in particular, internal enterprise repositories?
Going forward, these would ideally use the Addon SDK and hence not have
compat issues at all, right?
> This new versioning policy really hinders enterprise uptake.
More precisely, the policy of actually adding features when they're
ready as opposed to lumping them all together into big-bang releases
hinders enterprise uptake, right? That is, we could call this version
4.0.2, but since it has various incompatible changes (including various
new web-facing features) it's just as much of a problem for enterprises,
as I understand.
> With minor updates, it's not much of an issue because that implies nothing
> significant changed - just fixes and perhaps minor enhancements. Major
> releases require testing. Even though 5.0 is a minor update to 4.0
Defined how? There are various changes that could break compatibility
with binary extensions, non-binary extensions, and intranet sites....
> Faster releases don't break the enterprise, but a
> versioning policy where you can't tell what's major and what's minor does.
The real problem for enterprise deployments is that in the new setup
there is no such distinction. All updates will typically contain
substantive changes of some sort....
This was in fact considered. The problem is that we feel that we don't
have the developer resources to effectively dedicate a separate team to
doing long-term support of old versions, which is what it sounds like
enterprises want.
If IBM (or any combination of companies interested in such a thing)
wants to help maintain long-term-support branches of Firefox for
enterprise use, I'm pretty certain that would be very welcome.
-Boris
Paul Biggar
> On 6/22/2011 19:56, Paul Biggar wrote:
>>>
>>> Finally, EOLing a product that is merely weeks old (4.0) will also scare
>>> off enterprises
>>
>> Actually, we EOLed 4.0 a few weeks ago in favour of 4.0.1. Now we're
>> EOLing 4.0.1 in favour of 4.1^H^H^H5.0. There's nothing new or scary
>> here.
>
> I was referring to the 4.0 series, not a specific version - just like 3.6
> refers to the entire 3.6 series of releases.
In that case, the 4.0 series has not been EOLed, and will never be.
This is the 3rd release in the 4.0 series.
The point I'm making is that this stuff is just version number
semantics. We've changed the meaning of version numbers, and we're
actually hoping that they (version numbers) will quietly go away. We
certainly don't want this same argument going on when we release
Firefox 17.
timeless
> More precisely, the policy of actually adding features when they're ready as
> opposed to lumping them all together into big-bang releases hinders
> enterprise uptake, right? That is, we could call this version 4.0.2, but
> since it has various incompatible changes (including various new web-facing
> features) it's just as much of a problem for enterprises, as I understand.
I was pleasantly surprised to discover that my new employer had an
addon for Firefox. This of course was useless to me as I wanted to use
Nightly or perhaps Aurora.
As my employer's addon is private, it will never be in AMO, and that's ok.
Of note, intranets typically have lots of stuff which is version
pinned, and that's life. I just met a guy with a dozen versions of IE
installed just to deal w/ intranet sites.
The mythical testing cycle that people claim is required is not really
that useful. It turns out that it's generally much better to have two
things:
1. a fallback that will always work -- either a standalone application
or a basic web page
2. a way for people to try things and report problems -- it turns out
that users are much better able to test things than developers or
admins, they actually know how they want to use things, and by virtue
of crowd sourcing, you can choose to prioritize based on their
complaints.
Every time I go to a new version of Firefox, I have to spend a while
trying to figure out the right magical incantation required to enable
version overrides. This is incredibly annoying and not particularly
helpful to anyone.
A better approach would be a button next to each addon which isn't
known to be compatible which lets a user say "I understand this isn't
compatible, but I'd like to try it anyway". That should probably
trigger a mode where Firefox triggers extra logging, so when something
does go wrong, there's something useful that the user can provide to
the addon author.
One thing that I don't see anywhere is a standardized bug tracking
link. As an example, I have NoScript installed, and to this day, I
don't know how to report bugs for NoScript nor do I know how to check
to see if my bug is already reported. If NoScript was backed by a
bugzilla, then a link to NoScript's bugzilla would be rather useful.
As it happens, NoScript's about dialog does include a link to a
'changelog' which is sort of the <resolved> portion of a
<bug-tracker>.
An example of a less than happy extension is RealPlayer Browser Record Plugin
The "home page" is "http://www.real.com" -- I challenge anyone to find
that addon on its home page :(.
I don't know how good our addons are, but it's probably possible to
crowd source users to improve addon meta data and empower them to
improve addon compatibility uptake.
CH!LLY
upgrades while breaking add-ons, the once great automatic updating
system is now effectively broken right? You just went, we need to copy
chrome and f the users.
Dave Townsend
> On Wed, Jun 22, 2011 at 11:10 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
> > More precisely, the policy of actually adding features when they're ready
> as
> > opposed to lumping them all together into big-bang releases hinders
> > enterprise uptake, right? That is, we could call this version 4.0.2, but
> > since it has various incompatible changes (including various new
> web-facing
> > features) it's just as much of a problem for enterprises, as I
> understand.
>
> I was pleasantly surprised to discover that my new employer had an
> addon for Firefox. This of course was useless to me as I wanted to use
> Nightly or perhaps Aurora.
>
> As my employer's addon is private, it will never be in AMO, and that's ok.
>
> Of note, intranets typically have lots of stuff which is version
> pinned, and that's life. I just met a guy with a dozen versions of IE
> installed just to deal w/ intranet sites.
>
> The mythical testing cycle that people claim is required is not really
> that useful. It turns out that it's generally much better to have two
> things:
> 1. a fallback that will always work -- either a standalone application
> or a basic web page
> 2. a way for people to try things and report problems -- it turns out
> that users are much better able to test things than developers or
> admins, they actually know how they want to use things, and by virtue
> of crowd sourcing, you can choose to prioritize based on their
> complaints.
>
> Every time I go to a new version of Firefox, I have to spend a while
> trying to figure out the right magical incantation required to enable
> version overrides. This is incredibly annoying and not particularly
> helpful to anyone.
>
The good news is that since a short time ago, if you are using nightlies it
is extensions.checkCompatibility.nightly and will be whatever version of the
nightlies.
> A better approach would be a button next to each addon which isn't
> known to be compatible which lets a user say "I understand this isn't
> compatible, but I'd like to try it anyway". That should probably
> trigger a mode where Firefox triggers extra logging, so when something
> does go wrong, there's something useful that the user can provide to
> the addon author.
>
> I don't know how good our addons are, but it's probably possible to
> crowd source users to improve addon meta data and empower them to
> improve addon compatibility uptake.
>
You should take a look at the add-ons compatibility reporter, it is along
exactly these lines, it also means you don't have to remember any prefs to
enable incompatible add-ons.
Shawn Wilsher
> A better approach would be a button next to each addon which isn't
> known to be compatible which lets a user say "I understand this isn't
> compatible, but I'd like to try it anyway". That should probably
> trigger a mode where Firefox triggers extra logging, so when something
> does go wrong, there's something useful that the user can provide to
> the addon author.
does :D
Cheers,
Shawn
[1] https://addons.mozilla.org/firefox/addon/add-on-compatibility-reporter/
Paul Biggar
> On 6/22/2011 10:04 PM, timeless wrote:
>>
>> A better approach would be a button next to each addon which isn't
>> known to be compatible which lets a user say "I understand this isn't
>> compatible, but I'd like to try it anyway". That should probably
>> trigger a mode where Firefox triggers extra logging, so when something
>> does go wrong, there's something useful that the user can provide to
>> the addon author.
>
> This is pretty much what the Add-on Compatibility Reporter [1] add-on does
> :D
I'm starting to think we should ship this in stock Firefox. It would
go 99% of the way to solving every versioning complaint we've heard
about add-ons.
timeless
> The good news is that since a short time ago, if you are using nightlies it
> is extensions.checkCompatibility.nightly and will be whatever version of the
> nightlies.
Not helpful. I have to ask or search. I do find that (or did), but it
takes too long. It's a terrible waste of my time and doesn't help the
average user or the average person in a crowd.
timeless
> I'm starting to think we should ship this in stock Firefox. It would
> go 99% of the way to solving every versioning complaint we've heard
> about add-ons.
+1
Please.
timeless
> This is pretty much what the Add-on Compatibility Reporter [1] add-on does
> :D
> [1] https://addons.mozilla.org/firefox/addon/add-on-compatibility-reporter/
author not verified :(
It also makes the add-ons page unusable. On my IdeaPad, this is how
one of my add-ons appears:
Stylish 1.1.2
Restyle the w... More [Compatibility v] [ Options ] [ Disable ] [ Remove ]
Someone will need to work on collapsing the buttons so that they only
appear when a user clicks on the row, and so that they appear below
the description instead of eating into it.
Mike Hommey
> If IBM (or any combination of companies interested in such a thing)
> wants to help maintain long-term-support branches of Firefox for
> enterprise use, I'm pretty certain that would be very welcome.
Or RedHat, Novell, and other Linux distributors. One problem to
overcome, though, would be that of processes. AFAIK, we don't have
non-employee driven branches with automated build, test, etc.
Mike
PS: If we need more reasons why long term support is important:
http://mike.kaply.com/2011/06/23/understanding-the-corporate-impact/
timeless
> It also makes the add-ons page unusable. On my IdeaPad, this is how
> one of my add-ons appears:
>
> Stylish 1.1.2
> Restyle the w... More [Compatibility v] [ Options ] [ Disable ] [ Remove ]
>
> Someone will need to work on collapsing the buttons so that they only
> appear when a user clicks on the row, and so that they appear below
> the description instead of eating into it.
While I'm complaining about this, I should note that there is no way
for me to copy the text from the Add-ons manager. It looks like a web
page, and I trust that there's html behind it, but I can't select or
copy the text.
Consider this text from the extension you're advertising:
If you're an add-on developer trying to find reports submitted for
your extension, head over to the Report Viewer here:
https://addons.mozilla.org/compatibility/reporter
That url is *not* a link, and I do not want to have to type it ever again!
Oh, and the page I got dumped into when I installed it was:
https://addons.mozilla.org/en-US/firefox/pages/compatibility_firstrun
Which had this text:
If you upgrade to a new version of Firefox or update your add-ons,
your reports for the old versions will be hidden to allow you to test
the new version. If you have any questions, please ask in our forums.
I naively expected that <our forums> would be something related to the
extension (Add-on Compatibility whatever), but no, it's
<https://forums.addons.mozilla.org/>, which is hardly useful.
So yes, there are some minor things which should probably be improved
at some point. There's also the minor detail that I'm pretty sure
companies do not want their private addons having reports sent to
mozilla's public forums. So hopefully there's some way for them to be
directed elsewhere (as I noted initially). If there is, then the
descriptive text should be improved so people <don't panic>, because
my initial reading definitely didn't show any alternate path.
Asa Dotzler
Except that we automatically update add-ons that should be compatible
and the ones that aren't are likely to be real problems. Letting users
completely bust their Firefox installs with the many genuinely
incompatible extensions doesn't seem like a great solution to me.
- A
Boris Zbarsky
> AFAIK, we don't have non-employee driven branches with automated build, test, etc.
This seems like an eminently solvable problem.
-Boris