How do we update from Firefox 3.5 to 3.6?
Axel Hecht
we've discussed before if we're doing the update from 3.5 to 3.6 as
minor update.
Do we know what's going to drive that decision? I know that java was in
the game, that seems to be solved.
If we're doing it, by when, and by which criteria?
Just trying to figure out by when I need to answer which questions
regarding our localizations.
Axel
Mike Beltzner
> we've discussed before if we're doing the update from 3.5 to 3.6 as
> minor update.
Indeed, and this came up again in today's development meeting. I should
have replied to this thread sooner.
The motivation remains the same as when the notion was first discussed
early in the Firefox 3.6 development cycle: to quickly migrate our
existing user base to Firefox 3.6 / mozilla-1.9.2 based releases.
To date we have offered our users two different types of updates, which
we call "major" and "minor". Major updates have been for code which has
been in development for at least 12 months, features visible changes to
the user interface either in terms or appearance or interaction, and/or
contains major technology changes at the platform level which may cause
significant differences in system requirements or support requirements.
Minor updates have been for security and stability releases which do not
contain any visible user interface changes, and are limited in terms of
technological change.
We offer major updates as a choice that the user must accept, due to our
belief that the user should be able to decide whether or not they want
the new features and the change to their interactions. We force minor
updates without a choice (though all application updating can be
disabled) because we believe that the updates are important for users,
and that the new version of the product comes with all the benefits of
the older version without any additional cost. Further, we force minor
updates because we know that simply by virtue of offering a choice,
fewer users will accept the new version, and many of the users who
reject it will not reject it for the correct reasons (because they don't
understand the dialog, are resistant to change, do not understand the
costs and benefits, etc.)
The pace of technology development in web browsers is speeding up
rapidly, and we now face a challenge of ensuring that we can continue to
deliver modern web browsing experiences to our users. Many of these new
experiences do not result in any major user interface changes, instead
relying on improving performance, stability and enabling new web
technology features. As proposed earlier in the summer, Firefox 3.6 will
be primarily a release with security, stability, speed and capability
enhancements, with no visible user interface changes over Firefox 3.5.
As such, I think we should consider it as a candidate for a minor
update, stretching our definition of what types of updates we can
provide using that mechanism.
Finally, users' expectations of software have changed since the update
mechanism was introduced in Firefox 1.5. Many applications that browser
users interact with exist in the cloud, with updates pushed frequently
and transparently, without consultation. That wasn't the case only a few
years ago.
> Do we know what's going to drive that decision? I know that java was in
> the game, that seems to be solved.
The factors that will drive that decision are:
- compatibility concerns
- stability and user testing concerns
- logistics and timing concerns
// Compatibility concerns
Add-on compatibility is one of the large reasons why users do not move
from one version to another. Some (but few) minor updates break Add-on
compatibility, but to date we've had trouble ensuring that major updates
do not leave Add-ons in an incompatible state. As such, we've been
overly conservative, waiting for Add-on authors to mark their software
as compatible with the new version; this can take a long time. To help
with this, the Add-ons team will be creating a crowdsourcing application
that will allow beta testers to let us know if Add-ons work as expected,
thus reducing the testing requirements on Add-on authors themselves.
Website compatibility is another issue, though our QA team has solved
this by collecting data on commonly used websites and ensuring that our
new products remain compatible with those sites before we release. We
also depend on feedback during the beta cycle.
Finally, throughout the development cycle of Firefox 3.6 we have been
taking fewer invasive changes which should make it easier to reason
about and test for compatibility concerns.
// Stability and user testing concerns
Firefox 3.6 will have a shorter beta cycle than other releases, which is
a concern due to the number of blocking issues that have been found in
previous betas. However, as stated above, since we have taken fewer
invasive changes, it should be easier to focus our beta audience and the
areas for which we are concerned.
A recent focus on crash monitoring and analysis should give us better
tools to reason about stability of the product, but fundamentally, I
have problems with the idea that we'd consider a product "stable enough"
to put up on our website for download, yet not have the confidence to
issue it as an update to our user base.
// Logistics and timing concerns
We still need to do quite a bit of testing to ensure that a minor update
of this scale will work as expected. Further, if we were to ship it as a
minor update we would need to do so at a time when there will be enough
staff on hand to deal with questions and issues that may arise;
depending on the ship schedule for Firefox 3.6, this may force the
update to be some time after the product is available for download.
> If we're doing it, by when, and by which criteria?
This also hasn't been fully fleshed out, but it's possible to release
Firefox 3.6 and not update Firefox 3.5 users immediately. In the past
we've avoided doing that for bandwidth preservation reasons alone, and
we may wish to continue with that policy.
cheers,
mike
John J. Barton
...
> Firefox 3.6 will have a shorter beta cycle than other releases, which is
> a concern due to the number of blocking issues that have been found in
> previous betas.
Based on what I've seen so far, 3.6b1 resembles previous 3.Xb1 in that
it will be (from my perspective) not significantly better than nightly
builds. It seems that a lot of time and energy goes into the b1, but it
falls short. I don't think this is just "duh". Rather I think the
nightly build infrastructure is really excellent as far as it goes, but
whatever is going on after that does not add enough value at the b1
stage. The b1 becomes an instant reject because some few aspects don't
work for extensions which are vital to the beta user community. In
future, consider putting less energy into b1 and more energy into
shortening the distance between b1 and b2 where extensions have had a
chance to get fixes in. Perhaps even invent a "bx" release, explicitly
for this purpose.
jjb
John O'Duinn
In today's development meeting, there was some discussions about
Scenario#1 and Scenario#2 below. I'd like to propose Scenario#3, which
afaict meets the concerns raised.
Scenario#1:
===========
- on day of release of FF3.6.0, existing FF3.5.x users get a *minor*
update to FF3.6.0.
...which means:
-- by using that minor upgrade dialog, user will find it harder to see
what changed until *after* installation
-- users could be surprised by change in functionality (and UI?) when
they are used to only get small security fixes in a minor update
scenario. Downgrading is tricker? Would this surprise encourage users to
turn off getting Firefox updates in future?
-- concerns about new problems discovered only after a lot of users were
broken. Bad user experience.
-- mozilla will need to support one less branch. We still support
FF3.0.x, FF3.6.x but would no longer need to support FF3.5.x.
Scenario#2:
===========
- on day of release of FF3.6.0, existing FF3.5.x users get a prompted
*major* update.
...which means:
-- upgrade dialog box has details of what will change.
-- users would not be surprised by change.
-- mozilla will need to support FF3.5 in addition to FF3.0.x, FF3.6.x.
-- concerns about new problems discovered only after a lot of users were
broken. Bad user experience.
-- maybe less risk if we did this with FF3.6.1 instead?
Scenario#3:
===========
- on day of release of FF3.6.0, existing FF3.5.x users are not prompted
to update, but users can choose to manually-only *major* update to
FF3.6.0. This is just like we did for the release of FF3.5.0, was quite
used for 35-45% of upgrades, and we know our infrastructure can do this
safely.
- early adopters would pro-actively upgrade to 3.6.0
- we monitor for crash reports or any problems.
-- if there are no red flags after a week, we can proceed to:
-- start a *gradual* rollout of idle-background *major* update. AUS
allows us to gradually un-throttle MU prompts to idle-users, so only a
subset of users would see the prompt. Maybe start with 10%?
- if there are no red flags after another week, we can raise to 20%,
then 50%, then 100%.
...which means:
-- we have time to react to surprise bugs if needed
-- we can reverse throttling if needed to limit exposure to surprise
bugs as they are discovered.
-- user-visible upgrade dialog box has details of what changed.
-- we offer MU more quickly then we did for FF3.0->FF3.5
-- mozilla will need to support FF3.5 in addition to FF3.0.x, FF3.6.x.
Scenario#3 seems to meet the concerns I've heard in recent weeks, and
again today, but let me know if I missed/misunderstood anything.
tc
John.
=====
Mike Beltzner wrote:
> On 10/15/2009 8:05 PM, Axel Hecht wrote:
>> we've discussed before if we're doing the update from 3.5 to 3.6 as
>> minor update.
>
>> Do we know what's going to drive that decision? I know that java was in
>> the game, that seems to be solved.
>
> The factors that will drive that decision are:
>
> - compatibility concerns
> - stability and user testing concerns
> - logistics and timing concerns
>
> // Compatibility concerns
>
> Add-on compatibility is one of the large reasons why users do not move
> from one version to another. Some (but few) minor updates break Add-on
> compatibility, but to date we've had trouble ensuring that major updates
> do not leave Add-ons in an incompatible state. As such, we've been
> overly conservative, waiting for Add-on authors to mark their software
> as compatible with the new version; this can take a long time. To help
> with this, the Add-ons team will be creating a crowdsourcing application
> that will allow beta testers to let us know if Add-ons work as expected,
> thus reducing the testing requirements on Add-on authors themselves.
>
> Website compatibility is another issue, though our QA team has solved
> this by collecting data on commonly used websites and ensuring that our
> new products remain compatible with those sites before we release. We
> also depend on feedback during the beta cycle.
>
> Finally, throughout the development cycle of Firefox 3.6 we have been
> taking fewer invasive changes which should make it easier to reason
> about and test for compatibility concerns.
>
> // Stability and user testing concerns
>
> Firefox 3.6 will have a shorter beta cycle than other releases, which is
> a concern due to the number of blocking issues that have been found in
> previous betas. However, as stated above, since we have taken fewer
> invasive changes, it should be easier to focus our beta audience and the
> areas for which we are concerned.
>
> A recent focus on crash monitoring and analysis should give us better
> tools to reason about stability of the product, but fundamentally, I
> have problems with the idea that we'd consider a product "stable enough"
> to put up on our website for download, yet not have the confidence to
> issue it as an update to our user base.
>
> // Logistics and timing concerns
>
> We still need to do quite a bit of testing to ensure that a minor update
> of this scale will work as expected. Further, if we were to ship it as a
> minor update we would need to do so at a time when there will be enough
> staff on hand to deal with questions and issues that may arise;
> depending on the ship schedule for Firefox 3.6, this may force the
> update to be some time after the product is available for download.
>
>> If we're doing it, by when, and by which criteria?
>
> This also hasn't been fully fleshed out, but it's possible to release
> Firefox 3.6 and not update Firefox 3.5 users immediately. In the past
> we've avoided doing that for bandwidth preservation reasons alone, and
> we may wish to continue with that policy.
>
> cheers,
> mike
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
timeless
> minor update.
On Wed, Oct 21, 2009 at 7:12 AM, Mike Beltzner <belt...@mozilla.com> wrote:
> Indeed, and this came up again in today's development meeting. I should have
> replied to this thread sooner.
> The factors that will drive that decision are:
> - compatibility concerns
> - stability and user testing concerns
> - logistics and timing concerns
>
> // Compatibility concerns
> Add-on compatibility is one of the large reasons why users do not move from
> one version to another. Some (but few) minor updates break Add-on
> compatibility, but to date we've had trouble ensuring that major updates do
> not leave Add-ons in an incompatible state. As such, we've been overly
> conservative, waiting for Add-on authors to mark their software as
> compatible with the new version; this can take a long time. To help with
> this, the Add-ons team will be creating a crowdsourcing application that
> will allow beta testers to let us know if Add-ons work as expected, thus
> reducing the testing requirements on Add-on authors themselves.
It might be worth noting that at Nokia, we hit a huge rough patch
trying to update from 1.9.2pre to 1.9.2, namely, another group had a
NPAPI plugin using the XPCOM Scriptable Plugin solution (obsolete pre
Firefox 1.0, but they didn't ask us, and really refuse to let us
manage them or their priorities). For anyone using this plugin, the
update isn't a minor update, since it breaks it entirely (this has
effectively blocked our ability to upgrade to a remotely safe version
of Gecko for MicroB on the N900).
That group FWIW, seems to be interested in redoing their plugin to
work with a Nokia initiative (CWRT) which seems to mean that they
don't intend to deliver anything useful for a long time.
From a certain perspective, I'd actually encourage you to upgrade
everyone to FF3.6 so that these people will understand that their
priorities are backwards. OTOH, if you actually care about people who
might be using this plugin, you might want to do something else.
Oh, and as for confidentiality, this isn't. >300 people not working
for Nokia have N900s with Nokia Maps, and anyone can take a debug
pluginhost to the maps plugin and determine that it uses xpcom
scripting (or they could just look for the .xpt file!). As for CWRT,
"nokia common wrt",
http://justamp.blogspot.com/2009/01/nokia-wrt-plug-in-for-aptana-studio.html
it's also public knowledge.
Axel Hecht
and quality per localization.
I don't have reliable numbers on that right now, and given our
timeframe, I don't think I'll have some until really close to RC1. I
know at least one team where we won't have strong ownership 'til then.
What I know is that we have less than 40 locales with nightly testers,
and it's more like 10 locales with more than a dozen in the last week.
I would add that I recall our talks about this to be more towards doing
that upgrade on 3.6.1 than 3.6.0, and that framed the amount of outreach
we did so far, too.
We'll surely try to be up-to-par on 3.6 compared to 3.5 as quickly as we
can, but I don't have an ETA or a "that's how many users would get X
experience" until a good deal further down the road.
Axel
chris hofmann
> On 10/15/2009 8:05 PM, Axel Hecht wrote:
>> minor update.
>
>> the game, that seems to be solved.
>
that the tools are getting better but the facts remain that we need to
put all the crash fixes, compatibility fixes, security fixes out to a
wide audiances, then provide some time to get those things in use, then
assess. The tools we have can't preemptively measure how good we are on
each of these stability and performance vectors for the whole body of
the web and I think there is a long road to get them to that state.
Our efforts to change from a addon compatibility model where the author
confirms compatibility, to a model of assumed compatibility unless
users tells about the bad ones now puts addons in the same boat as the
stability and performance assessments. We'll need a body of 3, to 5, to
10 milllion users to tell us how we are doing there to understand and
assess where we are.
I also agree that all the browser makers want to, and are moving much
faster.
But I'll submit that browsers users might be organizing into three
camps, and I'll steal from Andrea Balle's analysis to describe them
There is the IE6 camp. These are the 'old volkswagon' users of the web.
The have some kind of strange comfort in something old and familiar
and available. There is not much that we should be doing for these
users other than to convince them to move to a modern browser.
There is the 'high performance sedan users of the web. This set of
users wants to drive the 5 passenger high performance sedan on the
autoban of the web in extreme comfort. They get extremely annoyed by
shakes, rattles, stability, compatibility and performance problems.
Everything should work flawlessly and be well designed and integrated.
There are the 'browser racing enthusiasts' of the web. These are the
forumal 1 browser users. The enjoy participating in the advancements,
thrills, and chills of the browser and web development. If there is not
a high pace of speed and advancement, and the occasional spectacular
blowout wreck, things just aren't moving fast enough. Here is one of
the many voices from the race track...
http://blog.internetnews.com/skerner/2009/10/mozilla-firefox-354-beta-now-a.html
I think we might be trying to make something in the middle. Its not
moving fast enough for the browser enthusiasts, and the fewer beta's,
and shorter beta bake times, along with and quick ramp up in update
migrations have the potencial to expose the 'high performance sedan'
users annoyances they just don't want to see.
Like the auto industry, I wonder if we to figure out how we could create
test vehicles for the track that had just the following of the browser
enthusiasts. A path like that could allow us to make improvements
that have the longer bake time needed to serve the 'high performance
sedan' browser users better.
This is all just theory and the classifications might not really exist.
One way to test this would be try and figure out these kind of users
acutally exist, and to find out how many of them there are out on the web.
Market share analysis might tell us that 30% are still old volkswagon
users. Googles 'what is a browser?' poll suggests that a only 90% of
users might not even know what a browser is. To me that suggests a
pretty high percentage might be in high performance sedan browser
classification. I also bet there are maybe 10 to 15 millon browser
enthusiasts out there. Firefox still holds a good many of these, and I
think we need to figure out how to do a better job of organizing them
and harnessing them to help us understand exactly where we are in terms
of stability, performance, security, and the other vectors that people
assess browser releases on before we unleash the a browser update to the
high perfomance sedan users.
-chofmann
> // Logistics and timing concerns
>
> We still need to do quite a bit of testing to ensure that a minor
> update of this scale will work as expected. Further, if we were to
> ship it as a minor update we would need to do so at a time when there
> will be enough staff on hand to deal with questions and issues that
> may arise; depending on the ship schedule for Firefox 3.6, this may
> force the update to be some time after the product is available for
> download.
>
>> If we're doing it, by when, and by which criteria?
>
> This also hasn't been fully fleshed out, but it's possible to release
> Firefox 3.6 and not update Firefox 3.5 users immediately. In the past
> we've avoided doing that for bandwidth preservation reasons alone, and
> we may wish to continue with that policy.
>
> cheers,
> mike
Robert Kaiser
> Finally, throughout the development cycle of Firefox 3.6 we have been
> taking fewer invasive changes which should make it easier to reason
> about and test for compatibility concerns.
But I think enough that it upset quite a number of people if we silently
force those changes upon them.
Robert Kaiser
Robert Kaiser
> Scenario#1:
> ===========
> [...]
> -- mozilla will need to support one less branch. We still support
> FF3.0.x, FF3.6.x but would no longer need to support FF3.5.x.
In that scenario, we might save that branch support for Firefox, but as
Thunderbird and SeaMonkey will ship major releases based on Mozilla
1.9.1 within the next few weeks, we will need to support that branch in
some way for some time anyhow, at least until those projects are ready
to release something on a post-1.9.1 branch.
Robert Kaiser
John J. Barton
> On 10/15/2009 8:05 PM, Axel Hecht wrote:
>> we've discussed before if we're doing the update from 3.5 to 3.6 as
>> minor update.
> // Compatibility concerns
>
> Add-on compatibility is one of the large reasons why users do not move
> from one version to another.
Now I am responding for the Firebug users rather than the Firebug
developers.
Based on the past Firefox update approach, Firebug versions span two
versions of Firefox:
# Firebug 1.3 works with Firefox 3.0 and Firefox 2.0
# Firebug 1.4 works with Firefox 3.0 and Firefox 3.5
# Firebug 1.5 will work with Firefox 3.5 and Firefox 3.6
Firebug 1.4 is not compatible with Firefox 3.6 and won't be. So if 3.6
overwrites 3.5, Firebug 1.4 users will have to manually install Firefox 3.5.
The existence, testing, and compatibility of Firebug 1.5 is not
relevant: these are Firebug 1.4 users and they will remain so until 1.5
has been out for many months. I have no idea how many people fit this
category.
Firebug may be unusual, but in general the model that an extension is
"compatible" with a version of Firefox does not work for us. Firebug is
not a stationary fixture. We are changing (maybe faster than Firefox?)
and we are very dependent on Firefox details. So even though Firefox
team may view 3.5 -> 3.6 as minor, Firebug users will see it as major
because they will be forced to adopt Firebug 1.5 at the same time.
jjb
Mike Beltzner
> Scenario#1:
> ===========
> - on day of release of FF3.6.0, existing FF3.5.x users get a *minor*
> update to FF3.6.0.
> ...which means:
> -- by using that minor upgrade dialog, user will find it harder to see
> what changed until *after* installation
The entire point is that from a user perspective, little to no visible
change will be present. Firefox will just be faster, more stable, and
do a bit more in terms of web technology support. The only visible UI
feature is support for a new type of theme, and that's not anything
that presents itself in the primary UI.
Further, the major update dialog doesn't really give users any
prescience into what the changes will be. The billboard we display is
usually a recap of our primary marketing messages.
> -- users could be surprised by change in functionality (and UI?) when
> they are used to only get small security fixes in a minor update
> scenario. Downgrading is tricker? Would this surprise encourage
> users to
> turn off getting Firefox updates in future?
I'll keep saying it: there is no change in functionality. There is no
visible change in UI.
> -- concerns about new problems discovered only after a lot of users
> were
> broken. Bad user experience.
> -- mozilla will need to support one less branch. We still support
> FF3.0.x, FF3.6.x but would no longer need to support FF3.5.x.
>
>
> Scenario#2:
> ===========
> - on day of release of FF3.6.0, existing FF3.5.x users get a prompted
> *major* update.
> ...which means:
> -- upgrade dialog box has details of what will change.
> -- users would not be surprised by change.
> -- mozilla will need to support FF3.5 in addition to FF3.0.x, FF3.6.x.
> -- concerns about new problems discovered only after a lot of users
> were
> broken. Bad user experience.
> -- maybe less risk if we did this with FF3.6.1 instead?
I think you're overestimating the value of the upgrade box, as
mentioned above. Also, this scenario fails to take into account that
once we offer Firefox 3.6 as a major update, it becomes increasingly
difficult (from a product presentation and messaging point of view) to
offer it as a minor update in the future. The major update offer
clearly provides the user a choice of whether or not they want to
upgrade, and I'd be hard pressed to remove that option later.
> Scenario#3:
> ===========
> - on day of release of FF3.6.0, existing FF3.5.x users are not
> prompted
> to update, but users can choose to manually-only *major* update to
> FF3.6.0. This is just like we did for the release of FF3.5.0, was
> quite
> used for 35-45% of upgrades, and we know our infrastructure can do
> this
> safely.
> - early adopters would pro-actively upgrade to 3.6.0
> - we monitor for crash reports or any problems.
> -- if there are no red flags after a week, we can proceed to:
> -- start a *gradual* rollout of idle-background *major* update. AUS
> allows us to gradually un-throttle MU prompts to idle-users, so only a
> subset of users would see the prompt. Maybe start with 10%?
> - if there are no red flags after another week, we can raise to 20%,
> then 50%, then 100%.
> ...which means:
> -- we have time to react to surprise bugs if needed
> -- we can reverse throttling if needed to limit exposure to surprise
> bugs as they are discovered.
> -- user-visible upgrade dialog box has details of what changed.
> -- we offer MU more quickly then we did for FF3.0->FF3.5
> -- mozilla will need to support FF3.5 in addition to FF3.0.x, FF3.6.x.
I think that this is mostly the same as what I wrote here:
>> This also hasn't been fully fleshed out, but it's possible to release
>> Firefox 3.6 and not update Firefox 3.5 users immediately. In the past
>> we've avoided doing that for bandwidth preservation reasons alone,
>> and
>> we may wish to continue with that policy.
or at least I intended to infer what you've written above. There's an
additional cost of producing and localizing the "billboard" for the
major update dialog, which takes time and localization.
cheers,
mike
Mike Beltzner
> It might be worth noting that at Nokia, we hit a huge rough patch
> trying to update from 1.9.2pre to 1.9.2, namely, another group had a
> NPAPI plugin using the XPCOM Scriptable Plugin solution (obsolete pre
> Firefox 1.0, but they didn't ask us, and really refuse to let us
> manage them or their priorities). For anyone using this plugin, the
> update isn't a minor update, since it breaks it entirely (this has
> effectively blocked our ability to upgrade to a remotely safe version
> of Gecko for MicroB on the N900).
This change occurred between 1.9.2a1 and 1.9.2b1? Or between 1.9.1.x
and 1.9.2? I'd be curious to know which bugs changed this and why.
> From a certain perspective, I'd actually encourage you to upgrade
> everyone to FF3.6 so that these people will understand that their
> priorities are backwards. OTOH, if you actually care about people who
> might be using this plugin, you might want to do something else.
Do we know who else would be using this plugin?
cheers,
mike
Mike Beltzner
> Firebug 1.4 is not compatible with Firefox 3.6 and won't be. So if
> 3.6 overwrites 3.5, Firebug 1.4 users will have to manually install
> Firefox 3.5.
Why manually instead of using the Add-on update system which allows
you to publish information about compatibility updates and then have
Firefox automatically install that update when it moves to the new
version?
> Firebug may be unusual, but in general the model that an extension
> is "compatible" with a version of Firefox does not work for us.
> Firebug is not a stationary fixture. We are changing (maybe faster
> than Firefox?) and we are very dependent on Firefox details. So even
> though Firefox team may view 3.5 -> 3.6 as minor, Firebug users will
> see it as major because they will be forced to adopt Firebug 1.5 at
> the same time.
Have you seen a large amount of developer reluctance to move from
Firebug 1.4 to 1.5? Is it not a superior product? Are you not eager to
have more users on the newer version? I think I'm a little confused by
the implication that being forced to move to Firebug 1.5 will be an
issue of contention for users.
Further, I would expect that many web developers are (sadly) used to
retaining an older version of Firefox on their system to use with
Firebug do to the lag we'd previously encountered between a Firefox
and compatible Firebug release.
cheers,
mike
Mike Beltzner
That's a fine thing to say, but in order to factor that into the
analysis it would be helpful if you could expand on what you consider
to be "quite a number of people" (note that we're now in a world where
upsetting 1M users is less than 1% of our total audience), as well as
what the cost of upsetting those users (f.e., OSX 10.6 broke a ton of
3rd party applications, yet few people ended up downgrading, instead
transferring their expectations onto those application vendors to
issue compatibility updates).
I think to reason properly about those things, it would help to know
which changes in mozilla-1.9.2 / Firefox 3.6 you believe will cause
users to be upset.
cheers,
mike
Boris Zbarsky
> This change occurred between 1.9.2a1 and 1.9.2b1? Or between 1.9.1.x and
> 1.9.2? I'd be curious to know which bugs changed this and why.
The latter; see https://bugzilla.mozilla.org/show_bug.cgi?id=498164
-Boris
Benjamin Smedberg
> This change occurred between 1.9.2a1 and 1.9.2b1? Or between 1.9.1.x and
> 1.9.2? I'd be curious to know which bugs changed this and why.
It changed before 1.9.2a1. It is part of restructuring the plugin host to
make the code cleaner, as well as preparation for Electrolysis and perhaps
changing the XPCOM ABI.
--BDS
Benjamin Smedberg
> Based on what I've seen so far, 3.6b1 resembles previous 3.Xb1 in that
> it will be (from my perspective) not significantly better than nightly
> builds. It seems that a lot of time and energy goes into the b1, but it
> falls short. I don't think this is just "duh". Rather I think the
> nightly build infrastructure is really excellent as far as it goes, but
> whatever is going on after that does not add enough value at the b1
> stage. The b1 becomes an instant reject because some few aspects don't
> work for extensions which are vital to the beta user community. In
> future, consider putting less energy into b1 and more energy into
> shortening the distance between b1 and b2 where extensions have had a
> chance to get fixes in. Perhaps even invent a "bx" release, explicitly
> for this purpose.
And I don't understand what you mean by "significantly better than nightly
builds". Typically the beta is a nightly build, done after we've fixed all
the bugs we consider serious enough to block a beta. Are you saying there
are bugs that should have blocked the beta, but didn't (and can you provide
examples)?
It seems like you're saying "beta1 is always bad because extensions are
broken". How can we help extension authors to test with the nightly builds
so that they aren't broken by the time we get to beta?
There is no planned beta2. The next milestone is the first release candidate.
--BDS
Benjamin Smedberg
> In that scenario, we might save that branch support for Firefox, but as
> Thunderbird and SeaMonkey will ship major releases based on Mozilla
> 1.9.1 within the next few weeks, we will need to support that branch in
> some way for some time anyhow, at least until those projects are ready
> to release something on a post-1.9.1 branch.
Although SeaMonkey and Thunderbird are basing current work on 1.9.1, I think
that it would be bad for the Mozilla community and future web work to
maintain yet another branch, which is one of the driving forces behind
making Firefox 3.6 a minor update. This means that the seamonkey and
thunderbird developers would end up being responsible for backporting
security patches to 1.9.1, or updating your code to work in 1.9.2. Either
way, I don't think that core gecko hackers and the security teams should be
signed up to maintain another branch.
--BDS
John J. Barton
> On 2009-10-21, at 11:45 AM, John J. Barton wrote:
>
>> Firebug 1.4 is not compatible with Firefox 3.6 and won't be. So if 3.6
>> overwrites 3.5, Firebug 1.4 users will have to manually install
>> Firefox 3.5.
>
> Why manually instead of using the Add-on update system which allows you
> to publish information about compatibility updates and then have Firefox
> automatically install that update when it moves to the new version?
I don't think the Add-on system will automatically downgrade Firefox if
an Add-on is not compatible. These are Firebug 1.4 users, not Firebug
users. That's my point.
>
>> Firebug may be unusual, but in general the model that an extension is
>> "compatible" with a version of Firefox does not work for us. Firebug
>> is not a stationary fixture. We are changing (maybe faster than
>> Firefox?) and we are very dependent on Firefox details. So even though
>> Firefox team may view 3.5 -> 3.6 as minor, Firebug users will see it
>> as major because they will be forced to adopt Firebug 1.5 at the same
>> time.
>
> Have you seen a large amount of developer reluctance to move from
> Firebug 1.4 to 1.5?
I can't answer since 1.5 does not yet exist. Numerically the vast
majority of Firebug users upgrade when we update AMO. But the long tail
is critical because it contains the majority of developers for large sites.
> Is it not a superior product?
By which criteria? Of course *I* think 1.5 is way better than 1.4. But
in one important category 1.5 is certain to be inferior: successfully
used by many users on many different sites.
> Are you not eager to
> have more users on the newer version?
Of course. My eagerness is not at issue however. ;-)
> I think I'm a little confused by
> the implication that being forced to move to Firebug 1.5 will be an
> issue of contention for users.
And we're a little confused by a Firefox 3.6 that can't decide if it is
3.6 or 3.5.5. If 3.6 is really minor, release it as 3.5.5. Else, well
then it's not minor after all.
> Further, I would expect that many web developers are (sadly) used to
> retaining an older version of Firefox on their system to use with
> Firebug do to the lag we'd previously encountered between a Firefox and
> compatible Firebug release.
Yes, this is exactly the issue we are discussing! But you are viewing
"compatible" as some kind of simple one-time test. But web devs view
"compatible" as "works 100% on my problems". We have no way of providing
that kind of compatibility other than by having users try it and report
bugs. That is why the overlapping version solution works for us. Some of
the community moves on to the new version, we fix bugs, then the
laggards join. By that time we are on the next version.
Another factor may be less important because of changes in the browser
arena. In the past web devs lagged because their users lagged: they had
to support back level browsers so they needed dev tools on back level
browsers.
Despite all of this I want to say I support shorter release cycles in
Firefox. Firebug shortened it cycle so we can be in sync. I'm just
trying to report how Firebug users may see this idea of pushing 3.6 on
top of 3.5 too soon. As I said before, I think the b1 should be sooner
and their should be a time when both 3.5 and 3.6 exist to support
transitions.
jjb
chris hofmann
> On 2009-10-21, at 11:24 AM, Robert Kaiser wrote:
>
> analysis it would be helpful if you could expand on what you consider
> to be "quite a number of people" (note that we're now in a world where
> upsetting 1M users is less than 1% of our total audience),
I think the concern Kiro is expressing here are the pool of users in the
'high performance sedan' analogy I posted earlier. When we upgrade
them we should do it at a time where 10 million browser enthusiast have
weighed in to tell us the release is ready for broader distribution.
Right now we are set to go from several hundred thousand or a million to
many tens of millons in a matter of days or weeks, and its
indiscriminate updating of both browser enthusiasts and browser
conasures that are expecting the highest reliability.
> as well as what the cost of upsetting those users (f.e., OSX 10.6
> broke a ton of 3rd party applications, yet few people ended up
> downgrading, instead transferring their expectations onto those
> application vendors to issue compatibility updates).
>
downgrading an OS is hard. downgrading or swtiching to another browser
is also hard for many but relatively easier.
> I think to reason properly about those things, it would help to know
> which changes in mozilla-1.9.2 / Firefox 3.6 you believe will cause
> users to be upset.
>
Its the unknown things that we learn in extended beta(s), rc(s), and
early part of releases that could be the biggest concern. compression
of that part of the development cycle means higher risk.
John O'Duinn
Mike Beltzner wrote:
> On 2009-10-21, at 6:36 AM, John O'Duinn wrote:
>
>> Scenario#1:
>> ===========
>> - on day of release of FF3.6.0, existing FF3.5.x users get a *minor*
>> update to FF3.6.0.
>> ...which means:
>> -- by using that minor upgrade dialog, user will find it harder to see
>> what changed until *after* installation
>
> The entire point is that from a user perspective, little to no visible
> change will be present. Firefox will just be faster, more stable, and do
> a bit more in terms of web technology support. The only visible UI
> feature is support for a new type of theme, and that's not anything that
> presents itself in the primary UI.
>
> Further, the major update dialog doesn't really give users any
> prescience into what the changes will be. The billboard we display is
> usually a recap of our primary marketing messages.
...which includes the outline of top new features, yes?
>
>> -- users could be surprised by change in functionality (and UI?) when
>> they are used to only get small security fixes in a minor update
>> scenario. Downgrading is tricker? Would this surprise encourage users to
>> turn off getting Firefox updates in future?
>
> I'll keep saying it: there is no change in functionality. There is no
> visible change in UI.
I'd accept "no known change in functionality", but yes, ok.
>> -- concerns about new problems discovered only after a lot of users were
>> broken. Bad user experience.
>> -- mozilla will need to support one less branch. We still support
>> FF3.0.x, FF3.6.x but would no longer need to support FF3.5.x.
>>
>>
>> Scenario#2:
>> ===========
>> - on day of release of FF3.6.0, existing FF3.5.x users get a prompted
>> *major* update.
>> ...which means:
>> -- upgrade dialog box has details of what will change.
>> -- users would not be surprised by change.
>> -- mozilla will need to support FF3.5 in addition to FF3.0.x, FF3.6.x.
>> -- concerns about new problems discovered only after a lot of users were
>> broken. Bad user experience.
>> -- maybe less risk if we did this with FF3.6.1 instead?
>
> I think you're overestimating the value of the upgrade box, as mentioned
> above. Also, this scenario fails to take into account that once we offer
> Firefox 3.6 as a major update, it becomes increasingly difficult (from a
> product presentation and messaging point of view) to offer it as a minor
> update in the future. The major update offer clearly provides the user a
> choice of whether or not they want to upgrade, and I'd be hard pressed
> to remove that option later.
I agree that once we start offering FF3.5->FF3.6 as a MU, its hard to
later change our minds and offer FF3.5->FF3.6 as a minor update. I think
we would stay one way or another.
err... reads quite different, but maybe you meant "not update all
Firefox"? Anyway, if you are asking "is scenario#3 possible", I confirm
this is mechanically possible.
Scenario#3 is something we can do mechanically, and feels like an
improvement over what we did for FF3.0->FF3.5.
While it feels so long ago now, I note that FF3.5 was the first time we
had MU available on the FF3.5 release day. And even then, it was for
manual-check-for-update only. Having FF3.5->FF3.6 MU available on FF3.6
release day for *all* users would be a big incremental step forward.
Lets try this before we start try
crossing-release-branches-with-minor-updates?
> There's an
> additional cost of producing and localizing the "billboard" for the
> major update dialog, which takes time and localization.
Yes, like we usually do.
> cheers,
> mike
tc
John.
Robert Kaiser
> On 2009-10-21, at 11:24 AM, Robert Kaiser wrote:
>
>> Mike Beltzner wrote:
>>> Finally, throughout the development cycle of Firefox 3.6 we have been
>>> taking fewer invasive changes which should make it easier to reason
>>> about and test for compatibility concerns.
>>
>> But I think enough that it upset quite a number of people if we
>> silently force those changes upon them.
>
> That's a fine thing to say, but in order to factor that into the
> analysis it would be helpful if you could expand on what you consider to
> be "quite a number of people" (note that we're now in a world where
> upsetting 1M users is less than 1% of our total audience), as well as
> what the cost of upsetting those users (f.e., OSX 10.6 broke a ton of
> 3rd party applications, yet few people ended up downgrading, instead
> transferring their expectations onto those application vendors to issue
> compatibility updates).
Umm, true, even though it's always hard to wrap my mind around that,
knowing that the product I'm managing has about 1M as the *total* user
base ;-)
> I think to reason properly about those things, it would help to know
> which changes in mozilla-1.9.2 / Firefox 3.6 you believe will cause
> users to be upset.
Where do we have those nice lists of things changed in the release? We
could try to sort out from there what has which impact.
IIRC, we for example removed the OJI support, which means that a number
of users will probably end up with broken Java unless they upgrade that
as well.
timeless has already mentioned XPCOM Scriptable Plugin support, there
might still be some plugins out there that use it, which also would just
stop working with a "minor" upgrade if we do that for 3.5->3.6.
I don't think being unable to import download history from Mozilla 1.8.*
and older is much of an issue for Firefox right now, but it's one of the
reasons why SeaMonkey needs to stick with 1.9.1 for a few months, where
SeaMonkey 1.x users still can migrate all their data.
There might be other things that pop up when we go through a changelog
piece by piece, as my product is only concentrating on 1.9.1 for now,
I'm far from an expert on 1.9.2 changes.
Robert Kaiser
Shawn Wilsher
> IIRC, we for example removed the OJI support, which means that a number
> of users will probably end up with broken Java unless they upgrade that
> as well.
/sdwilsh
Robert Kaiser
Gecko and security teams (as well as Linus distro teams) are still doing
some maintenance for 1.8 branch at this time, and have been doing so for
quite some time. Would you prefer to have them prolong maintaining that
for two or three months while we make sure Thunderbird and SeaMonkey can
ship from 1.9.2 or would you prefer us releasing on 1.9.1 now and have
them maintaining that branch for a bit?
Robert Kaiser
Benjamin Smedberg
> Gecko and security teams (as well as Linus distro teams) are still doing
> some maintenance for 1.8 branch at this time, and have been doing so for
> quite some time. Would you prefer to have them prolong maintaining that
> for two or three months while we make sure Thunderbird and SeaMonkey can
> ship from 1.9.2 or would you prefer us releasing on 1.9.1 now and have
> them maintaining that branch for a bit?
Those are not the only options: you could release off of 1.9.1 now, and do a
minor update in TB3.0.2 switching to the 1.9.2 gecko base. That is the
solution I recommend.
I believe Mozilla as a community should focus on moving the web forward. If
TBird/SeaMonkey are going to cause lots of friction and maintenance, as a
community we should lower our support, rather than accepting the
security/maintenance friction of another active security branch.
--BDS
timeless
> This change occurred between 1.9.2a1 and 1.9.2b1? Or between 1.9.1.x and
> 1.9.2? I'd be curious to know which bugs changed this and why.
We removed support for the deprecated scriptable plugin api, it was
deprecated before FF1.0, and should have been removed ages ago. I
think we finally were able to remove it once Java updated to not
require it.
I see that bz gave the ref (bug 498164), I'm sorry that i didn't
include it in my post.
and biesi corrected the actual description of which supported thing
was removed https://developer.mozilla.org/en/Scripting_Plugins_in_Mozilla
>> From a certain perspective, I'd actually encourage you to upgrade
>> everyone to FF3.6 so that these people will understand that their
>> priorities are backwards. OTOH, if you actually care about people who
>> might be using this plugin, you might want to do something else.
>
> Do we know who else would be using this plugin?
I believe it's used for maps.ovi.com, so in theory anyone who visits
there on Windows could have received it. The plugin is rather custom,
so it's unlikely to be useful for any web site that isn't
maps.ovi.com. Sadly, I'm unclear as to the true heritage of this
plugin, so I can't say if there are related plugins elsewhere....
In general, I'm vaguely tempted to go on a plugin treasure hunt to see
if i can find others that use the removed API. OTOH, I'm not sure I
want to meet any more such treasures. The one I met was scary enough.
To some extent, I think the easiest way for us to discover which other
plugins are like this is to let the public detect them and tell us. It
sucks of course, but ....
In terms of simple methods to identify such plugins, searching for xpt
files in plugin distributions should work. I believe that plugins w/o
xpt files can not possibly use this api (unless they limit themselves
to gecko apis, which would be well... technically possible but rather
unlikely). It'd probably be a task we could give to someone from QA,
like tomcat? :)
Robert Kaiser
For all platforms or only for Mac? I thought it was just the latter...
Robert Kaiser
Robert Kaiser
> Those are not the only options: you could release off of 1.9.1 now, and do a
> minor update in TB3.0.2 switching to the 1.9.2 gecko base. That is the
> solution I recommend.
SeaMonkey can't do that, as we need to be able to import SeaMonkey 1.1.x
data at least for a few dot-releases, and 1.9.2 can't.
Robert Kaiser
David Ascher
> On 10/21/09 3:37 PM, Robert Kaiser wrote:
>
>
>> Gecko and security teams (as well as Linus distro teams) are still doing
>> some maintenance for 1.8 branch at this time, and have been doing so for
>> quite some time. Would you prefer to have them prolong maintaining that
>> for two or three months while we make sure Thunderbird and SeaMonkey can
>> ship from 1.9.2 or would you prefer us releasing on 1.9.1 now and have
>> them maintaining that branch for a bit?
>>
> Those are not the only options: you could release off of 1.9.1 now, and do a
> minor update in TB3.0.2 switching to the 1.9.2 gecko base. That is the
> solution I recommend.
>
[short post for lack of time]
Making a release of TB built off of 1.9.2 is our first priority after
TB3 ships. We need to ramp up 1.9.2 builders, and fix the breakage on
trunk before we know how hard that will be. I've been operating under
the assumption that we couldn't call it 3.0.N because of add-on
compatibility breakage that we expect from Gecko (even if we don't
change any TB APIs). In my head it's called 3.1, although we may
consider a minor update for the same reasons that Firefox is considering
a minor update to 3.6. In fact I suspect it should be easier for us
than for Firefox because:
1) We don't have as large a number of add-ons
2) Given how long it's been since a major release, I expect many users
will be conservative and wait for 3.next no matter what we say =)
2) In my head anyway, the only true release-blocker for 3.1 is "built on
1.9.2", so development time will hopefully be short. If it's not a
3.0.N, we'll probably ride-along a few fixups for things that will
undoubtedly have been found to be wrong w/ 3.0, but nothing big or hairy.
I agree that TB will need to hop along with Gecko versions as fast as
possible, because there simply aren't resources to do effective security
backports across many branches. What's not clear is how long 'as fast
as possible' ends up being, from a QA point of view. Over time, I think
we all need to get our users to upgrade more frequently than many are
used to. We just need to make the upgrade experience pleasant (not
break stuff, be consistently better, etc.), and I think most will go
along. Those that don't go along will effectively be making a
deliberate choice, and we just need to make the consequences clear.
If anyone is keen to help, the easiest way to ensure we can move along
while maintaining quality is to help with our automated test coverage.
We have a million times more automated tests than we did in 2.0, but we
need a lot more.
--david
Frédéric Buclin
>> I'll keep saying it: there is no change in functionality. There is no
>> visible change in UI.
> I'd accept "no known change in functionality", but yes, ok.
You seem to forget the controversial removal of the "Properties" item
from the context menu:
https://bugzilla.mozilla.org/show_bug.cgi?id=513147
This change is not minor to some users (me included), even if they don't
reach the 1M users limit:
https://bugzilla.mozilla.org/show_bug.cgi?id=515368
https://bugzilla.mozilla.org/show_bug.cgi?id=517902
https://bugzilla.mozilla.org/show_bug.cgi?id=522913
This removal alone explains why I'm not using 3.6b1 (build2) yet.
Arguing that 3.5.x -> 3.6 is minor is untrue, from this point of view.
And those who refuse to do this upgrade won't get any security fix
anymore as there won't be any other 3.5.x release.
LpSolit
Joshua Cranmer
> Add-on compatibility is one of the large reasons why users do not move
> compatibility, but to date we've had trouble ensuring that major updates
> do not leave Add-ons in an incompatible state. As such, we've been
> overly conservative, waiting for Add-on authors to mark their software
> as compatible with the new version; this can take a long time. To help
> with this, the Add-ons team will be creating a crowdsourcing application
> that will allow beta testers to let us know if Add-ons work as expected,
> thus reducing the testing requirements on Add-on authors themselves.
As I understand it, most add-ons right now would be specifying 3.5.* as
the max version compatibility and would be doing so until some point
after the 3.6 release (but hopefully not much longer), right? If that is
true, pushing 3.6 as a minor update would essentially be an update that
suddenly causes most if not all of your extensions to stop working, and
one that most users won't know how to prevent from happening.
If one were to push 3.6 like that, I would expect the public backlash to
be brutal, since the remedies will pretty much tell people to go through
a screen that says "you really shouldn't touch this." Either that, or
you have to get most of the add-on authors to QA their add-ons and push
changes to up the max-version to 3.6 before pushing the FF update (which
necessitates /waiting/ on them to do so). Which I expect would take
longer than the normal release-it-as-a-major-version setup anyways.
In case you couldn't tell, I'm strongly in favor of sticking to the
normal major update stuff.
Jesse Ruderman
scenario 1) but throttle the rate of automatic updates to a controlled
exponential rampup (like in scenario 3)?
This way, if problems are found in crash-stats, the number of users
affected is limited, but we still get almost everyone updated within a
month or two.
Axel Hecht
From the experience we have with 1.9.2, lifting over the comm-central
l10n work to 1.9.2 will not be trivial. Though, once that's done,
getting something for 1.9.3 might come for free, depending on timing.
Axel
Shawn Wilsher
> As I understand it, most add-ons right now would be specifying 3.5.* as
> the max version compatibility and would be doing so until some point
> after the 3.6 release (but hopefully not much longer), right? If that is
> true, pushing 3.6 as a minor update would essentially be an update that
> suddenly causes most if not all of your extensions to stop working, and
> one that most users won't know how to prevent from happening.
time we release 3.6? That's probably not what's going to happen based
on current discussions, so I'm not sure how this is completely valid.
> If one were to push 3.6 like that, I would expect the public backlash to
> be brutal, since the remedies will pretty much tell people to go through
> a screen that says "you really shouldn't touch this." Either that, or
> you have to get most of the add-on authors to QA their add-ons and push
> changes to up the max-version to 3.6 before pushing the FF update (which
> necessitates /waiting/ on them to do so). Which I expect would take
> longer than the normal release-it-as-a-major-version setup anyways.
Don't people already promote this on every update?
Cheers,
Shawn
Joshua Cranmer
>> If one were to push 3.6 like that, I would expect the public backlash to
>> be brutal, since the remedies will pretty much tell people to go through
>> a screen that says "you really shouldn't touch this." Either that, or
>> you have to get most of the add-on authors to QA their add-ons and push
>> changes to up the max-version to 3.6 before pushing the FF update (which
>> necessitates /waiting/ on them to do so). Which I expect would take
>> longer than the normal release-it-as-a-major-version setup anyways.
> Don't people already promote this on every update?
How long does it typically take the extension authors to update their
extensions?
Lucas Adamski
has evolved for good reason, which is that those are fundamentally
different propositions to the end user (and even more so to
enterprises).
Silent updates should only reduce risk from a security, stability and
general usability/compatibility standpoint.
Major updates introduce new attack surface due to new features, and
present new risks of stability and usability issues due to UI changes,
features changes or architectural refactoring, but also provide neat
new things (for users and/or developers) to take advantage of. UI
changes are not the only criteria for differentiating between a major
and minor update. For a given user, a major update may or may not be
considered an actual improvement, depending on their priorities.
And while we never intend a release to ship with major security,
stability or usability issues, despite the best efforts of mice and
men we (and everyone else shipping software of such complexity)
continue to do so. At least for some significant portion of our users.
Part of the story about permitting product-driven updates in
enterprises is a clear differentiator between updates and new
releases. We have had some luck with organizations permitting auto-
update with Firefox because it just sort of works and doesn't
introduce functionality issues nor does it impact the security
implications and assumptions. To blur the line between updates and
new releases can be a bit regressive as it will encourage
organizations to disable auto update and certify updates manually,
which is something most enterprises would dearly like to avoid IMHO.
I don't think the majority of our users are that different. People
switch to Firefox for a lot of reasons but I think chief among them
are security, performance, customization, functionality and a general
perception of trust. Even those leading edge users that evangelize
the latest and greatest browser features I think realize that, when
they are recommending a browser to their neighbor, friend or relative,
that individuals goals are less about having the latest CSS support
and more about general user experience, security, privacy and
satisfaction.
If the fundamental problem we are trying to solve is less about
deploying new features aggressively and more about supporting too many
releases simultaneously, then that's a problem we should discuss. A
sliding window model where we support each minor release for some
smaller amount of time before driving users to the next minor version,
with a longer support window for each major version, might be an option.
Lucas.
On Oct 20, 2009, at 9:12 PM, Mike Beltzner wrote:
> On 10/15/2009 8:05 PM, Axel Hecht wrote:
>> we've discussed before if we're doing the update from 3.5 to 3.6 as
>> minor update.
>
> Indeed, and this came up again in today's development meeting. I
> should have replied to this thread sooner.
>
> The motivation remains the same as when the notion was first
> discussed early in the Firefox 3.6 development cycle: to quickly
> migrate our existing user base to Firefox 3.6 / mozilla-1.9.2 based
> releases.
>
> To date we have offered our users two different types of updates,
> which we call "major" and "minor". Major updates have been for code
> which has been in development for at least 12 months, features
> visible changes to the user interface either in terms or appearance
> or interaction, and/or contains major technology changes at the
> platform level which may cause significant differences in system
> requirements or support requirements. Minor updates have been for
> security and stability releases which do not contain any visible
> user interface changes, and are limited in terms of technological
> change.
>
> We offer major updates as a choice that the user must accept, due to
> our belief that the user should be able to decide whether or not
> they want the new features and the change to their interactions. We
> force minor updates without a choice (though all application
> updating can be disabled) because we believe that the updates are
> important for users, and that the new version of the product comes
> with all the benefits of the older version without any additional
> cost. Further, we force minor updates because we know that simply by
> virtue of offering a choice, fewer users will accept the new
> version, and many of the users who reject it will not reject it for
> the correct reasons (because they don't understand the dialog, are
> resistant to change, do not understand the costs and benefits, etc.)
>
> The pace of technology development in web browsers is speeding up
> rapidly, and we now face a challenge of ensuring that we can
> continue to deliver modern web browsing experiences to our users.
> Many of these new experiences do not result in any major user
> interface changes, instead relying on improving performance,
> stability and enabling new web technology features. As proposed
> earlier in the summer, Firefox 3.6 will be primarily a release with
> security, stability, speed and capability enhancements, with no
> visible user interface changes over Firefox 3.5. As such, I think we
> should consider it as a candidate for a minor update, stretching our
> definition of what types of updates we can provide using that
> mechanism.
>
> Finally, users' expectations of software have changed since the
> update mechanism was introduced in Firefox 1.5. Many applications
> that browser users interact with exist in the cloud, with updates
> pushed frequently and transparently, without consultation. That
> wasn't the case only a few years ago.
>
>> Do we know what's going to drive that decision? I know that java
>> was in
>> the game, that seems to be solved.
>
> The factors that will drive that decision are:
>
> - compatibility concerns
> - stability and user testing concerns
> - logistics and timing concerns
>
> // Compatibility concerns
>
> Add-on compatibility is one of the large reasons why users do not
> move from one version to another. Some (but few) minor updates break
> Add-on compatibility, but to date we've had trouble ensuring that
> major updates do not leave Add-ons in an incompatible state. As
> such, we've been overly conservative, waiting for Add-on authors to
> mark their software as compatible with the new version; this can
> take a long time. To help with this, the Add-ons team will be
> creating a crowdsourcing application that will allow beta testers to
> let us know if Add-ons work as expected, thus reducing the testing
> requirements on Add-on authors themselves.
>
> Website compatibility is another issue, though our QA team has
> solved this by collecting data on commonly used websites and
> ensuring that our new products remain compatible with those sites
> before we release. We also depend on feedback during the beta cycle.
>
> Finally, throughout the development cycle of Firefox 3.6 we have
> been taking fewer invasive changes which should make it easier to
> reason about and test for compatibility concerns.
>
> // Stability and user testing concerns
>
> Firefox 3.6 will have a shorter beta cycle than other releases,
> which is a concern due to the number of blocking issues that have
> been found in previous betas. However, as stated above, since we
> have taken fewer invasive changes, it should be easier to focus our
> beta audience and the areas for which we are concerned.
>
> A recent focus on crash monitoring and analysis should give us
> better tools to reason about stability of the product, but
> fundamentally, I have problems with the idea that we'd consider a
> product "stable enough" to put up on our website for download, yet
> not have the confidence to issue it as an update to our user base.
>
> // Logistics and timing concerns
>
> We still need to do quite a bit of testing to ensure that a minor
> update of this scale will work as expected. Further, if we were to
> ship it as a minor update we would need to do so at a time when
> there will be enough staff on hand to deal with questions and issues
> that may arise; depending on the ship schedule for Firefox 3.6, this
> may force the update to be some time after the product is available
> for download.
>
>> If we're doing it, by when, and by which criteria?
>
> This also hasn't been fully fleshed out, but it's possible to
> release Firefox 3.6 and not update Firefox 3.5 users immediately. In
> the past we've avoided doing that for bandwidth preservation reasons
> alone, and we may wish to continue with that policy.
>
Gervase Markham
> If the fundamental problem we are trying to solve is less about
> deploying new features aggressively and more about supporting too many
> releases simultaneously, then that's a problem we should discuss.
I think this is important. Are we arguing about one possible solution
rather than looking at the problem?
> A
> sliding window model where we support each minor release for some
> smaller amount of time before driving users to the next minor version,
> with a longer support window for each major version, might be an option.
There are two competing issues here:
- We want users to be on the latest version, for their safety and
the best experience, and so we don't have to support older ones;
vs.
- Users may not want to be on the latest version.
This second desire can be because of:
1) The "not right now" factor when the dialog pops
2) Concern that things will break (either consumer or enterprise concern)
If we push 3.6 as a minor update, then we avoid users not upgrading due
to issue 1 - because there is no dialog. However, it means it's also
harder for them to opt out due to issue 2.
We can argue that they shouldn't be worried about issue 2, because we
rock and have fantastic QA. However, the web is a big place. We regress
stuff already when we do security updates, which contain only limited
changes. What are the chances we haven't broken anything important in
six months of development?
Gerv
Benjamin Smedberg
> As I understand it, most add-ons right now would be specifying 3.5.* as
> the max version compatibility and would be doing so until some point
> after the 3.6 release (but hopefully not much longer), right? If that is
Why would that be true? At the 3.5 release, most extensions had compatible
versions (IIRC, 95% of users would have no problems, and 85% of extensions
in AMO were compatible).
Part of doing a minor update would be making sure we had good extension
outreach and trying to get most extensions compatible before doing the
update to 3.6.
--BDS
Benjamin Smedberg
What are the technical reasons you can't? This sounds like something that
can be solved pretty easily.
--BDS
chris hofmann
https://addons.mozilla.org/en-US/firefox/compatibility
34% are compat with latest 3.6
and other 16% compat with 3.6a1
40-50% still to go, plus popular addons that aren't served by AMO
that translates into much cat herding still to be done
over the last several releases it typically it has taken 3-6 months to
do the outreach and compatibility checking needed to get the top 95% of
addons by usage to around an 85-90% compatibility level once we hit
feature freeze and started making commitments to try and not break
addons. 3.6 could go faster if we have clearly outlined things that
might break addons, and that list is minimal.
-chofmann
> --BDS
Axel Hecht
Let me ask the obvious, how is the compat rating on 3.5 right now? I
don't see that on the site.
Axel
chris hofmann
https://wiki.mozilla.org/WeeklyUpdates/2009-07-27#Add-ons
> Axel
Shawn Wilsher
> What are the technical reasons you can't? This sounds like something that
> can be solved pretty easily.
downloads.rdf in 1.9.2.
Cheers,
Shawn
Shawn Wilsher
> that translates into much cat herding still to be done
which we haven't done yet?
Cheers,
Shawn
John J. Barton
> On 10/21/09 7:16 PM, Joshua Cranmer wrote:
>
>> As I understand it, most add-ons right now would be specifying 3.5.* as
>> the max version compatibility and would be doing so until some point
>> after the 3.6 release (but hopefully not much longer), right? If that is
>
> Why would that be true? At the 3.5 release, most extensions had compatible
> versions (IIRC, 95% of users would have no problems, and 85% of extensions
> in AMO were compatible).
AMO currently does not support different extensions versions for
different versions of Firefox. At 3.5 Firebug artificially asserted
compatibility with 3.5 since we had no other choice. I don't know if
other extensions also made that choice and we don't want to do it again.
>
> Part of doing a minor update would be making sure we had good extension
> outreach and trying to get most extensions compatible before doing the
> update to 3.6.
And part of the outreach should be, in my opinion, a time when both 3.5
and 3.6 releases are available. That way extensions developers have a
window for triaging problems that occur on FF 3.6 between their code and
Firefox.
As long as we have this overlap time I don't think add-ons care so much
what you do in terms of the upgrade process.
jjb
chris hofmann
here is the timeline for 3.5 once things got pretty locked and loaded as
far as addon affecting changes.
I'm not sure you could call us at the "locked and loaded" state yet, are we?
The 3.5 timeline below represents a pretty good profile for minimal
negative press coverage or blogging about having a poor upgrade
experience due to addon incompatibility. we shipped fx 1.5 with
compatibility around the 70% level I think, and got hammered.
t-minus 7 wks https://wiki.mozilla.org/WeeklyUpdates/2009-05-11#Add-ons
3.5 Compatibility now at 56%, up 5% from last week. Compatibility
mailer going out this afternoon
t-minus 6 wks to ship
https://wiki.mozilla.org/WeeklyUpdates/2009-05-18#Add-ons
60% compatibility this week, up 4%
t-minus 4 wks https://wiki.mozilla.org/WeeklyUpdates/2009-06-01
Compatibility up to 67%
* Only major add-ons who haven't moved are Java Console and Firebug
o Firebug with 3.5.* compatibility in alpha
o Java Console may be abandoned, we're investigating
t-3 wks ttps://wiki.mozilla.org/WeeklyUpdates/2009-06-08#Add-ons
Compatibility with 3.5 up to 72% thanks to Sun updating the Java
Console entry- should be up another 3-4% once they complete testing
of the new Java Console
t-2 weeks https://wiki.mozilla.org/WeeklyUpdates/2009-06-15#Add-ons
Compatibility up to almost 80% for 3.5.*
* Most of the remaining add-ons are in the long tail, we're now
approaching developers directly to see if they'll upgrade
t-1 wk https://wiki.mozilla.org/WeeklyUpdates/2009-06-22#Add-ons
81% Compatibility
t-1 day https://wiki.mozilla.org/WeeklyUpdates/2009-06-29#Add-ons
Compatibility up to 83% for Fx 3.5
3.5 ship date 2009-06-30
t+ 1 wks https://wiki.mozilla.org/WeeklyUpdates/2009-07-06#Add-ons
90% of hosted add-ons compatible with 3.5.*
t+ 2 wks https://wiki.mozilla.org/WeeklyUpdates/2009-07-13#Add-ons
92% of hosted add-ons compatible with 3.5.*
t+ 4 wks https://wiki.mozilla.org/WeeklyUpdates/2009-07-27#Add-ons
94% of add-ons compatible with 3.5, due to increased usage of
3.5
-chofmann
>
> Cheers,
>
> Shawn
Nick Nguyen
We're trying something new with 3.6- when Beta 1 ships we're going to
offer a Compatibility Reporter extension on the first run page. This
extension is essentially an attempt to crowdsource compatibility
testing- it disables the checkcompat flag and lets users vote on
extensions they feel are compatible. Votes will trigger emails to
authors with embedded links that update AMO with the appropriate
compatibility. This is over and above the existing process, which
involves lots of emails and helpful tips.
-n.
>
> ---------- Forwarded message ----------
> From: chris hofmann<chof...@meer.net>
> Date: Thu, Oct 22, 2009 at 9:44 AM
> Subject: Re: How do we update from Firefox 3.5 to 3.6?
> To: Benjamin Smedberg<benj...@smedbergs.us>
> Cc: dev-pl...@lists.mozilla.org
> here is the current state
>
> https://addons.mozilla.org/en-US/firefox/compatibility
>
> 34% are compat with latest 3.6
> and other 16% compat with 3.6a1
> 40-50% still to go, plus popular addons that aren't served by AMO
>
> that translates into much cat herding still to be done
>
> over the last several releases it typically it has taken 3-6 months to
> do the outreach and compatibility checking needed to get the top 95%
> of addons by usage to around an 85-90% compatibility level once we hit
> feature freeze and started making commitments to try and not break
> addons. 3.6 could go faster if we have clearly outlined things that
> might break addons, and that list is minimal.
>
> -chofmann
>
>> --BDS
Robert Kaiser
Which we probably would have requested to happen post-1.9.2 if we knew
the current story, but back then things looked different.
I guess the whole OJI and XPCOM Scriptable Plugin discussion would have
been different as well with this in mind, but back then it was clear
that 1.9.2 would be another major step and it's OK to throw things out.
Robert Kaiser
Daniel Veditz
> we are very dependent on Firefox details. So even though Firefox
> team may view 3.5 -> 3.6 as minor, Firebug users will see it as major
> because they will be forced to adopt Firebug 1.5 at the same time.
If firebug were built into the browser, as similar tools are built into
other vendor's browsers, then that would happen as a matter of course.
You could even rename them Firebug 3.5 and 3.6 to stress they are tied
to particular versions of the browser (which I admit is a pain if you
use the same profile on multiple browser versions, but that tends to be
a bad idea).
John J Barton
> On 10/21/09 8:45 AM, John J. Barton wrote:
>> we are very dependent on Firefox details. So even though Firefox
>> team may view 3.5 -> 3.6 as minor, Firebug users will see it as major
>> because they will be forced to adopt Firebug 1.5 at the same time.
>
> If firebug were built into the browser, as similar tools are built into
> other vendor's browsers, then that would happen as a matter of course.
Yes, that's one of the strong arguments against building Firebug into
Firefox. Completely synchronous releases would require creating a huge
test suite, I guess it would be a big as Firefox's suite is now. That's
a big hill to climb.
>
> You could even rename them Firebug 3.5 and 3.6 to stress they are tied
I proposed that some time ago.
http://blog.getfirebug.com/2009/03/16/feature-renumbering-firebug-releases/
I would summarize the feedback as 100% negative.
> to particular versions of the browser (which I admit is a pain if you
> use the same profile on multiple browser versions, but that tends to be
> a bad idea).
? That is pretty much how we work all of the time.
The ability to test improvements in Firebug against a known-good version
of Firefox is a huge win for JS code. Every time I work against trunk it
takes me more than twice as long to do anything, because I hit
newly-created bugs or something breaks and I don't know who to blame.
jjb
Benjamin Smedberg
> AMO currently does not support different extensions versions for
> different versions of Firefox. At 3.5 Firebug artificially asserted
> compatibility with 3.5 since we had no other choice. I don't know if
> other extensions also made that choice and we don't want to do it again.
Can you explain what this means? You can certainly have a version of Firebug
compatible with Firefox 2-3 and another one compatible with 3.5-3.6 (or
whatever your current situation is). Do you mean that the older version is
not offered to users of the older branch?
--BDS
Benjamin Smedberg
Is that something SM can re-enable in their own code instead of in the
download manager itself? Or is it something that's hard to re-add in toolkit
to help SM/TB with upgrades?
--BDS
Benjamin Smedberg
> Branch maintenance replacement
> ==============================
> At this moment, Firefox 3.5 has been out for nearly four months and it
> will most likely be out for roughly six months when Firefox 3.6 will be
> released as far as I understand the current release schedule.
>
> That will essentially mean, that the 1.9.0 branch will no longer be
> maintained with security and stability fixes according to the current
> policy as far as I'm aware. So we're not really talking about
> "maintaining another branch". We're talking about replacing the
> maintenance of one older branch (whose first public release will be
> roughly 18 months old when 3.6 will be released) with the maintenance of
> a younger branch (whose first public release is just six month old).
>
> So releasing 3.6 as a minor update and not supporting 3.5-based release
> with further security and stability fixes would essentially mean, that
> you would have to further maintain an 18 month old release (with a much
> older branch) instead of maintaining a much younger codebase.
No it wouldn't. Whether we do 3.6 as a major or minor update has little
bearing on whether we continue to support 3.0: the six month clock is
already ticking and will expire on December 31 either way.
> Platform reliability
> ====================
> You will essentially tell every major consumer of the Mozilla platform
> that he is screwed, because you're now telling him that he needs to
> release at the same time or just a very few weeks after a major Firefox
> release to be able to get any kind of security and stability fixes from
> the platform owner.
>
> You should accept the fact that you're in a whole different game now. Not
> only is Firefox much bigger now than it was 3-4 years ago. The platform
> is also much more popular than it was at the time of Firefox 1.0 or
> Firefox 1.5. And MoCo development staff is much bigger now than 3-4 years
> ago as well.
>
> The current policy of maintaining a stable branch for just six months
> after the following release is out is already burdensome enough for many
> platform consumers. Breaking this already pretty weak promise will doom
> the platform entirely. Would you base your application on a platform that
> is not even guaranteed to be supported by the platform vendor for just 12
> months (in a 6-month release cycle)? I highly doubt it.
I think this deserves its own discussion, and I will try to write up my
thoughts more clearly in long form soon. Part of the basis for this
decision, though, is that by doing shorter release cycles such as 3.6/3.7 we
are significantly reducing the delta between "major" versions of the
platform, which should make it easier to upgrade to them.
--BDS
Benjamin Smedberg
> I think the model of providing opt-in major and silent minor updates has
> evolved for good reason, which is that those are fundamentally different
> propositions to the end user (and even more so to enterprises).
>
> Silent updates should only reduce risk from a security, stability and
> general usability/compatibility standpoint.
>
> Major updates introduce new attack surface due to new features, and
> present new risks of stability and usability issues due to UI changes,
> features changes or architectural refactoring, but also provide neat new
> things (for users and/or developers) to take advantage of. UI changes
> are not the only criteria for differentiating between a major and minor
> update. For a given user, a major update may or may not be considered
> an actual improvement, depending on their priorities.
If "always reducing risk" were the clear expectation of minor updates, when
we shouldn't do 3.6 as a minor update; but I disagree with the premise.
Most users want us to make their life better, as long as it doesn't require
mental attention from them. Since we aren't introducing significant UI
changes and hope to have almost complete addon compatibility, and have
significantly improved performance in 3.6, an upgrade should be basically a
non-event for most users.
Maybe we should default to just making major updates happen without
prompting as long as extensions are fully compatible. Then paranoid users or
businesses could change that default so that major updates always prompted
as they do today.
> Part of the story about permitting product-driven updates in enterprises
> is a clear differentiator between updates and new releases. We have had
I do not think that enterprise requirements should drive our decisions... we
have decided (and should continue) to make decisions based on the needs of
individual users, because trying to solve enterprise requirements requires a
much larger support system that we cannot afford.
I think there is certainly a place for a company to provide long-term
support and certification services; I just don't think it's part of the
Mozilla project (or MoCo) scope to do so.
> I don't think the majority of our users are that different. People
> switch to Firefox for a lot of reasons but I think chief among them are
> security, performance, customization, functionality and a general
> perception of trust. Even those leading edge users that evangelize the
> latest and greatest browser features I think realize that, when they are
> recommending a browser to their neighbor, friend or relative, that
> individuals goals are less about having the latest CSS support and more
> about general user experience, security, privacy and satisfaction.
We have known major improvements in stability and performance in the 3.6
line. Some of these can be backported to 3.5, but in general we believe that
3.6 is just a better browser, and that we can continue to meet high
expectations in security, customization, and general trust.
--BDs
timeless
> Maybe we should default to just making major updates happen without
> prompting as long as extensions are fully compatible.
Extensions and Plugins, but yes. This is what I'd like to see.
> Then paranoid users or
> businesses could change that default so that major updates always prompted
> as they do today.
No opinion. If we do the right thing by ensuring that everything is
compatible, then if the company deploys an incompatible plugin, the
right thing happens for free. If they happen to have a web app that
breaks, they'll need to update it anyway.
Robert Kaiser
It's toolkit code, and has been completely removed from the DM code
right now, need to defer to Shawn for how hard it would be to add back.
Of course, that doesn't mean that we did any in-depth investigation if
anything else like that would come up, that's one we at least know about.
We have done no testing whatsoever of SeaMonkey on 1.9.2 yet, and we
know mozilla-central-based builds have a few unexpected functional
breakages which could exist on 1.9.2 as well.
Robert Kaiser
chris hofmann
If
-the set of installed addons and plugins are fully compatible
-if the update is universally more compatible with websites
-if its universally more performant in all areas including start up,
page loading, UI interactaction, ....
-if it uses the same or less memory under all operating conditions
-if it crashes less
-if it is universally more secure
then there is no need to prompt the user for the update. All these
vectors affect the user experience, not just the fact there are no
significant UI changes. The problem is around how to understand the
state of all those vectors. And the 8 months of changes to the trunk
that have happened with no significant beta testing or large pool of
users helping to assess the current state.
The main problem is around how to understand each of these vectors with
fewer and shorter beta periods.
[snip enterprise section. I think you missed the main point.
individuals are also fussy about being updated and seeing regressions.
this is the main driver of end user release fatigue]
>> I don't think the majority of our users are that different. People
>> switch to Firefox for a lot of reasons but I think chief among them are
>> security, performance, customization, functionality and a general
>> perception of trust. Even those leading edge users that evangelize the
>> latest and greatest browser features I think realize that, when they are
>> recommending a browser to their neighbor, friend or relative, that
>> individuals goals are less about having the latest CSS support and more
>> about general user experience, security, privacy and satisfaction.
>>
>
> We have known major improvements in stability and performance in the 3.6
> line.
how much more faster and stable is 3.6? can we answer questions like that?
we know that we have attempted changes that will lead to possible
outcomes that would make
firefox faster and more stable. we have little information about what
possible side effects
might have resulted from those changes. that's what large betas are about.
> Some of these can be backported to 3.5, but in general we believe that
> 3.6 is just a better browser, and that we can continue to meet high
> expectations in security, customization, and general trust.
>
>
there were lots of "we believe" and "we hope" thoughts scattered
throughout your prose. The key thing is to figure out how to replace
those with higher levels of understanding and assessment, to help reduce
risk.
-chofmann
> --BDs
Benjamin Smedberg
> It's toolkit code, and has been completely removed from the DM code
> right now, need to defer to Shawn for how hard it would be to add back.
Just because it's toolkit code does not mean that there couldn't be
application code to import the old data, although let's see how sdwilsh
wants to approach it.
> Of course, that doesn't mean that we did any in-depth investigation if
> anything else like that would come up, that's one we at least know about.
> We have done no testing whatsoever of SeaMonkey on 1.9.2 yet, and we
> know mozilla-central-based builds have a few unexpected functional
> breakages which could exist on 1.9.2 as well.
Sure. But that's really a question of SeaMonkey development resources, right?
--BDS
John J. Barton
Firebug versions are generally compatible with two versions of Firefox.:
# Firebug 1.3 works with Firefox 3.0 and Firefox 2.0
# Firebug 1.4 works with Firefox 3.0 and Firefox 3.5
# Firebug 1.5 works with Firefox 3.5 and Firefox 3.6
All versions are available on getfirebug.com/releases. From our point of
view you are a Firebug 1.4 user running on either FF 3.0 or FF 3.5.
AMO looks at the table reversed:
Firefox 2.0 -> Firebug 1.3
Firefox 3.0 -> Firebug 1.4
Firefox 3.5 -> Firebug 1.5b // Here is the bug!
Firefox 3.6b -> Firebug 1.5b
So once we put Firebug 1.5b on AMO, our Firefox 3.5 users get forced
onto it, even if we only want Firefox 3.6b users. If we limit 1.5b to FF
3.6b, then FF 3.5 users can't install it.
In my opinion, with the current technology, the only solution is to
leave Firebug 1.4 on AMO until Firefox 3.6.0 is released and until
Firebug 1.5 is ready for all users. This means the Firefox 3.6b users
will think Firebug is not compatible unless they use the getfirebug.com
releases.
jjb
Shawn Wilsher
> It's toolkit code, and has been completely removed from the DM code
> right now, need to defer to Shawn for how hard it would be to add back.
SeaMonkey could also add it's own import code (even written in JS) for
it too (outside of the download manager code).
Cheers,
Shawn
John J. Barton
...
> Maybe we should default to just making major updates happen without
> prompting as long as extensions are fully compatible.
Perhaps I am belaboring this point, but in practice determining
extension compatibility is an experiment conducted with large numbers of
users. That means we need FF 3.6 and FF 3.5 for a overlapping period of
time, the time it takes for a large number of users to try the extension
while they still have a fall back option. So update 3.5 -> 3.6 without
prompts or what ever you like, but give us a window first.
jjb
Boris Zbarsky
> Benjamin Smedberg wrote:
> ....
Maybe I misunderstood Benjamin, but it sounded like he was proposing
that for any given user, if all the extensions _that_particular_user_
has installed are marked as compatible with the new release then we
should just do the major update. In the limiting case, if there are no
extensions installed we should just do the major update.
Benjamin, was that the proposal?
-Boris
Boris Zbarsky
> So once we put Firebug 1.5b on AMO, our Firefox 3.5 users get forced
> onto it, even if we only want Firefox 3.6b users. If we limit 1.5b to FF
> 3.6b, then FF 3.5 users can't install it.
>
> In my opinion, with the current technology, the only solution is to
> leave Firebug 1.4 on AMO until Firefox 3.6.0 is released and until
> Firebug 1.5 is ready for all users.
This seems like a strictly worse solution than putting up Firebug 1.5b
and marking it as compatible with 3.6+ for now.
Indeed, there seem to be the following user demographics (immediately
after 3.5 release):
1) Want to be using Firefox 3.5 and Firebug 1.4. Same outcome in both
options: it works fine.
2) Want to be using Firefox 3.5 and Firebug 1.5. Same outcome in both
options: it doesn't work via AMO. I believe it's possible to have the
extension installable from getfirebug (that is, have its internal
version listed as 3.5+) while still restricting it to 3.6+ on AMO, no?
So in both cases you can have this setup working from getfirebug.
3) Want to be using Firefox 3.6 and Firebug 1.4. Same outcome in both
options: it doesn't work.
4) Want to be using Firefox 3.6 and Firebug 1.5. In the one solution
this means having to manually visit getfirebug; in the other it just
works via AMO.
Seems like putting the new version on AMO and listing it not compatible
for Firefox 3.5 via the AMO mechanism is a strict win for group #4 and
no change for groups 1-3.
-Boris
John J. Barton
> On 10/23/09 11:46 AM, John J. Barton wrote:
>> So once we put Firebug 1.5b on AMO, our Firefox 3.5 users get forced
>> onto it, even if we only want Firefox 3.6b users. If we limit 1.5b to FF
>> 3.6b, then FF 3.5 users can't install it.
>>
>> In my opinion, with the current technology, the only solution is to
>> leave Firebug 1.4 on AMO until Firefox 3.6.0 is released and until
>> Firebug 1.5 is ready for all users.
>
> This seems like a strictly worse solution than putting up Firebug 1.5b
> and marking it as compatible with 3.6+ for now.
>
> Indeed, there seem to be the following user demographics (immediately
> after 3.5 release):
>
> 1) Want to be using Firefox 3.5 and Firebug 1.4. Same outcome in both
> options: it works fine.
That is not my understanding. If a Firefox 3.5 user seeks Firebug they
will see find that it is incompatible or they will not see it at all if
the search based on there browser version. These are the users that
complained during the 1.4/FF 3.5 change over.
>
> 2) Want to be using Firefox 3.5 and Firebug 1.5. Same outcome in both
> options: it doesn't work via AMO. I believe it's possible to have the
> extension installable from getfirebug (that is, have its internal
> version listed as 3.5+) while still restricting it to 3.6+ on AMO, no?
> So in both cases you can have this setup working from getfirebug.
Yes.
>
> 3) Want to be using Firefox 3.6 and Firebug 1.4. Same outcome in both
> options: it doesn't work.
We plan to test this option before doing anything on AMO. If this is
successful we may go with Firebug 1.4/3.6 for now.
>
> 4) Want to be using Firefox 3.6 and Firebug 1.5. In the one solution
> this means having to manually visit getfirebug; in the other it just
> works via AMO.
And since these are really FF 3.6b1 users, a hardy bunch, I think they
will have no trouble to find getfirebug.com/releases.
>
> Seems like putting the new version on AMO and listing it not compatible
> for Firefox 3.5 via the AMO mechanism is a strict win for group #4 and
> no change for groups 1-3.
My assessment is that group #1 (laggards) is pitted against group #4
(early adopters).
jjb
Mike Beltzner
collate feedback and respond en masse. If you're looking to save some
of your own time, though, here are some high level responses:
// Add-ons
I mentioned this in my original post, and indeed when we first began
discussing this plan months ago, if we do not reach a level of Add-on
compatibility that is considered to be satisfactory (as measured both
by an overall proportion of Add-ons, and a proportion of Add-ons as
ranked by usage) we won't issue an update. Period. We're not
interested in making users unhappy, and this has been considered.
Specific issues regarding Firebug seem uniquely complex, and I suggest
that an offline discussion between John Barton and Nick Nguyen would
quickly eradicate any misundertanding; certainly more quickly than can
be done in the context of this thread.
// Plugins
We need to get out ahead of the curve, and not wait for plugins to
cause crashes. Steps can and will be taken to this end.
// Stability Concerns
By not releasing an update immediately, but allowing some users to
download the product, we can get some early indication of stability
problems that we may not see in beta. Additionally by ensuring that we
run RCs against the most popular websites and items that were known to
cause stability problems in the past, we may be able to mitigate this
in advance.
// Platform Consumers
There are some good concerns here about what this means for SeaMonkey,
Thunderbird, and other platform consumers, though I think those
questions are less germane to the immediate decision about Firefox and
more to our support policy for old branches. I suggest we separate the
conversations.
More soon,
mike
Benjamin Smedberg
> Maybe I misunderstood Benjamin, but it sounded like he was proposing
> that for any given user, if all the extensions _that_particular_user_
> has installed are marked as compatible with the new release then we
> should just do the major update. In the limiting case, if there are no
> extensions installed we should just do the major update.
>
> Benjamin, was that the proposal?
Yes.
--BDS
Shawn Wilsher
> That is not my understanding. If a Firefox 3.5 user seeks Firebug they
> will see find that it is incompatible or they will not see it at all if
> the search based on there browser version. These are the users that
> complained during the 1.4/FF 3.5 change over.
Firebug that is compatible with the version of the browser the user is
using?
/sdwilsh
John J. Barton
Justin Scott says this will be fixed in future:
http://groups.google.com/group/mozilla.dev.amo/browse_thread/thread/2985d3e68c6d747a
jjb
>
> /sdwilsh
Robert Kaiser
Well, I think think we'll have any significant developer resources to
actually do that before 1.9.3 branching is already very near, and that's
why our target was to just move on to 1.9.3 straight away and just keep
the 1.9.1-based version in a strict maintenance mode. What you all are
doing here is to replan our project's schedule from the outside, which
is hard to swallow in any case :(
Robert Kaiser
Boris Zbarsky
> how much more faster and stable is 3.6? can we answer questions like that?
We can answer the "faster" question insofar as such a question can be
answered: for specific scenarios, we can list the difference.
* Sunspider is about 20% faster on my machine.
* Some microbenchmarks (e.g. setting .style.something) are about
3x faster.
* Some layout/dom manipulation tests are "much faster" (change from
O(N^2) to O(N) behavior, so the speedup depends on the size of the
page; 100x speedups are pretty easy).
* Some things are not significantly faster at all.
Stability would involve some data gathering; I don't have any numbers on
it offhand.
> we have little information about what possible side effects
> might have resulted from those changes. that's what large betas are about.
Sure. I think we should be prepared to reevaluate the situation if
unexpected things come up.
I think we should also work to pin down what criteria we plan to use to
make this decision, and if we don't know how to measure some of them try
to come up with a plan for doing so.
-Boris
chris hofmann
> On 10/23/09 10:46 AM, chris hofmann wrote:
>> how much more faster and stable is 3.6? can we answer questions like
>> that?
>
> We can answer the "faster" question insofar as such a question can be
> answered: for specific scenarios, we can list the difference.
>
> * Sunspider is about 20% faster on my machine.
> * Some microbenchmarks (e.g. setting .style.something) are about
> 3x faster.
> * Some layout/dom manipulation tests are "much faster" (change from
> O(N^2) to O(N) behavior, so the speedup depends on the size of the
> page; 100x speedups are pretty easy).
> * Some things are not significantly faster at all.
>
> Stability would involve some data gathering; I don't have any numbers
> on it offhand.
>
people, get them to use it for a few days or few weeks, then measure.
that is the state of the art for measuring crashiness and coming up with
very rough overall measures like:
http://people.mozilla.com/~chofmann/crash-data/crash-353-3014-ramp.png
http://people.mozilla.com/~chofmann/crash-data/crashes-per-1-users.png
>> we have little information about what possible side effects
>> might have resulted from those changes. that's what large betas are
>> about.
>
> Sure. I think we should be prepared to reevaluate the situation if
> unexpected things come up.
>
> I think we should also work to pin down what criteria we plan to use
> to make this decision, and if we don't know how to measure some of
> them try to come up with a plan for doing so.
>
yeah. agree.
> -Boris
Benjamin Smedberg
> measuring stability requires we get a good beta out to a large number of
> people, get them to use it for a few days or few weeks, then measure.
> that is the state of the art for measuring crashiness and coming up with
> very rough overall measures like:
Sure, and we're doing that now, right? Do you have a proposed target number
of beta users that would give us enough confidence to make 3.6 a minor update?
--BDS
Benjamin Smedberg
> // Stability Concerns
>
> By not releasing an update immediately, but allowing some users to
> download the product, we can get some early indication of stability
> problems that we may not see in beta. Additionally by ensuring that we
> run RCs against the most popular websites and items that were known to
> cause stability problems in the past, we may be able to mitigate this in
> advance.
We should also consider whether we are going to make 3.6 beta, or the 3.6
release candidates, minor updates for users currently on the 3.5 beta
channel. I believe we should.
--BDS
chris hofmann
I used to be confident that we could predict overall crashiness for the
our total user population once we had 40,000 thousand users or so, but
that was several years ago. Since the user base has grown so
dramatically (even in the last year it doubled again to over 100m active
daily users) it takes a lot more users to understand where we are. I
think it might be a million or more beta testers. Maybe several million
before how we will understand how well any version will stand up to the
use patterns of 100+ million users.
The metrics team is also thinking about this and figure out if there is
a way to do more with fewer users and less data.
your idea of using the 3.5beta channel is a good start to getting a
large user population on the beta.
> --BDS
Daniel Veditz
> Benjamin Smedberg<benj...@smedbergs.us> wrote:
>> Maybe we should default to just making major updates happen without
>> prompting as long as extensions are fully compatible.
>
> Extensions and Plugins, but yes. This is what I'd like to see.
Plugins do not announce a compatibility range, we have to assume plugins
are always compatible.
Unless you mean we should do something like put known-incompatible
plugins on the blocklist, and that the update process would check the
blocklist and if upgrading would result in an unblocked extension or
plugin getting blocked treat that as an incompatible addon.
We of course have no code to do that, and unless we switch to a slow
roll-out strategy we're not likely to find out about incompatible
plugins until it's too late to do any good (unless it's a major plugin,
which we're likely to get fixed or worked around before ship).
Daniel Veditz
> The metrics team is also thinking about this and figure out if there is
> a way to do more with fewer users and less data.
Larger numbers of users increase the odds someone will randomly hit
something, but that kind of thing is not likely to be a significant
stability impact. It's really the kind of user, and we don't get many
"average" users trying out the beta.
We have to peer past the beta top-crashes and somehow dig in and spot
the odd correlations that might later represent millions of users and
become a future top-crash. I don't know if that's possible.
Daniel Veditz
> We should also consider whether we are going to make 3.6 beta, or the 3.6
> release candidates, minor updates for users currently on the 3.5 beta
> channel. I believe we should.
ugh -- that steals all my 1.9.1.x branch testers.
Please don't minor update to the 3.6 beta. A prompted Major Update,
maybe, but most folks on the beta update channel came in at the end of
the beta period and not the beginning. If you're just going to force
them with a minor update wait for the release candidates which more
closely correspond in quality level (we hope) to what they're getting
from security-release betas.
Frank
On the subject of Compatibility concerns and themes, 3.6 will break
all and every 3.5 theme, unless updated first by the theme author.
The required changes are not major, time-wise, but will have to be
done by the authors. The full screen button will display the entire
toolbar.png if not coded for (this is an easy fix, but looks dramatic
if not fixed). The Notification popup breaks randomly if a small code
snippet is not added to global/global.css and some themes will not
install at all unless the file/jar structure is changed...etc.
For those theme authors on Addons, guess who users will blame if all
those themes are auto updated without change? :)
I would stress that compared to version updating from 3.0 > 3.5 and
especially (!) from 2.0 > 3.0, the required changes are minor, but do
need to be done. Perhaps an early Addons Dev reminder Email to theme
authors is the best solution to all this.
Frank :)
Frank
http://groups.google.com/group/mozilla.dev.planning/msg/83f5574db1ba1df5
gave me the impression that this was a new topic. I see now that in
fact there has been no less than 79 replies to it!
My apologies if the points that I raised, have already been raised
earlier on. :)
Mike Beltzner
> On the subject of Compatibility concerns and themes, 3.6 will break
> all and every 3.5 theme, unless updated first by the theme author.
That's concerning; do you have a good list of what's changed, theme
wise, between Firefox 3.5 and Firefox 3.6?
> The required changes are not major, time-wise, but will have to be
> done by the authors. The full screen button will display the entire
> toolbar.png if not coded for (this is an easy fix, but looks dramatic
> if not fixed). The Notification popup breaks randomly if a small code
> snippet is not added to global/global.css and some themes will not
> install at all unless the file/jar structure is changed...etc.
Is that an exhaustive list? I wonder if those tasks could be automated
or scripted?
> For those theme authors on Addons, guess who users will blame if all
> those themes are auto updated without change? :)
>
> I would stress that compared to version updating from 3.0> 3.5 and
> especially (!) from 2.0> 3.0, the required changes are minor, but do
> need to be done. Perhaps an early Addons Dev reminder Email to theme
> authors is the best solution to all this.
Jorge is your man in this regard, and has said that he'll be starting
that outreach soon, if he hasn't already. I'm wondering, though, Frank,
if you could be our ambassador on MozillaZine?
cheers,
mike
Jorge Villalobos
I strongly recommend that whoever is aware of the important theme
changes for 3.6 to edit this page:
https://developer.mozilla.org/en/Updating_themes_for_Firefox_3.6
The current version of this page doesn't even suggest such dramatic
changes, and as it is will be mostly ignored.
I'll be notifying the authors of the top extensions about updating to
3.6 on Wednesday, simultaneously as beta 1 is rolled out. I will also
create some discussion topics in our developer forums
(https://forums.addons.mozilla.org/). I also recommend you make theme
authors aware of these forums; we're trying to make them the go-to place
for technical discussion, and the theme development section is mostly
inactive at the moment.
- Jorge
Mike Beltzner wrote:
> On 10/26/2009 9:57 PM, Frank wrote:
>> On the subject of Compatibility concerns and themes, 3.6 will break
>> all and every 3.5 theme, unless updated first by the theme author.
>
> That's concerning; do you have a good list of what's changed, theme
> wise, between Firefox 3.5 and Firefox 3.6?
>
>> The required changes are not major, time-wise, but will have to be
>> done by the authors. The full screen button will display the entire
>> toolbar.png if not coded for (this is an easy fix, but looks dramatic
>> if not fixed). The Notification popup breaks randomly if a small code
>> snippet is not added to global/global.css and some themes will not
>> install at all unless the file/jar structure is changed...etc.
>
> Is that an exhaustive list? I wonder if those tasks could be automated
> or scripted?
>
>> For those theme authors on Addons, guess who users will blame if all
>> those themes are auto updated without change? :)
>>
>> I would stress that compared to version updating from 3.0> 3.5 and
>> especially (!) from 2.0> 3.0, the required changes are minor, but do
>> need to be done. Perhaps an early Addons Dev reminder Email to theme
>> authors is the best solution to all this.
>
Philip Chee
> I'll be notifying the authors of the top extensions about updating to
> 3.6 on Wednesday, simultaneously as beta 1 is rolled out. I will also
> create some discussion topics in our developer forums
> (https://forums.addons.mozilla.org/). I also recommend you make theme
> authors aware of these forums; we're trying to make them the go-to place
> for technical discussion, and the theme development section is mostly
> inactive at the moment.
That's because most themers consider the mozillazine theme dev forum to
be the go-to place for technical discussion. Ditto for extension authors
in the extension dev forum. I'm not sure if your attempt to split the
addons community in two is a good thing.
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.
[ ]Sure, Patrick, but will the Pontiac do warp nine?!
* TagZilla 0.066.6
Mike Beltzner
> be the go-to place for technical discussion. Ditto for extension authors
> in the extension dev forum. I'm not sure if your attempt to split the
> addons community in two is a good thing.
Then we'll count on you to make sure to point them to the information,
or mirror the information on MozillaZine. There's no intent to split the
community, Philip.
cheers,
mike
Michael Lefevre
That doesn't make much sense to me. Splitting the community might be
overstating it somewhat, but mirroring information between two sets of
forums seems likely to make a mess of communications. If you want
feedback on the information posted, will the AMO folks read the existing
forums for that, or should someone copy and paste the feedback from the
unofficial forums into the official forums?
Maybe it's idealistic, but wouldn't it be better to arrange some kind of
coordinated transition rather than just throwing up new forums and
hoping for the best? (Unless there is some reason the official forums
cannot completely replace the unofficial ones?)
Michael
Benjamin Smedberg
> I'll be notifying the authors of the top extensions about updating to
> 3.6 on Wednesday, simultaneously as beta 1 is rolled out. I will also
> create some discussion topics in our developer forums
> (https://forums.addons.mozilla.org/).
Argh, we have *another* extension developer forum? That means we now have
two mozilla-official fora (mozilla.dev.extensions and the new AMO one) and
the MozillaZine fora, which are awful but refuse to die.
What was wrong with mozilla.dev.extensions that we needed to create another
venue?
--BDS
Mike Beltzner
> Argh, we have *another* extension developer forum? That means we now
> have
> two mozilla-official fora (mozilla.dev.extensions and the new AMO
> one) and
> the MozillaZine fora, which are awful but refuse to die.
>
> What was wrong with mozilla.dev.extensions that we needed to create
> another
> venue?
I humbly suggest this is a topic for another thread, and in that
thread, I will humbly suggest that we either kill
mozilla.dev.extensions or have it be a 1:1 mirror of whatever addons.mozilla.org
is using.
cheers,
mike
Shawn Wilsher
> That doesn't make much sense to me. Splitting the community might be
> overstating it somewhat, but mirroring information between two sets of
> forums seems likely to make a mess of communications. If you want
this information for multiple releases now. We also have the
mozilla.dev.extensions newsgroup. Both of these are "official"
locations for this information. The new developer hub on AMO is trying
to combine the two.
> feedback on the information posted, will the AMO folks read the existing
> forums for that, or should someone copy and paste the feedback from the
> unofficial forums into the official forums?
Unless the environment on MozillaZine has changed drastically from the
past, I don't think that's feasible. That community is far to abusive
to individuals from Mozilla when they disagree with something Mozilla
has done.
Cheers,
Shawn
Philip Chee
>> That's because most themers consider the mozillazine theme dev forum to
>> be the go-to place for technical discussion. Ditto for extension authors
>> in the extension dev forum. I'm not sure if your attempt to split the
>> addons community in two is a good thing.
>
> Then we'll count on you to make sure to point them to the information,
Kuden is doing this far more effectively than I ever could:
<http://forums.mozillazine.org/viewtopic.php?f=18&t=975065>
<http://forums.mozillazine.org/viewtopic.php?f=18&t=1418995>
<http://forums.mozillazine.org/viewtopic.php?f=18&t=1363305>
You should really thank her somehow.
> or mirror the information on MozillaZine. There's no intent to split the
> community, Philip.
Glad to hear that.
John J Barton
> On 10/27/09 4:05 AM, Michael Lefevre wrote:
>> That doesn't make much sense to me. Splitting the community might be
>> overstating it somewhat, but mirroring information between two sets of
>> forums seems likely to make a mess of communications. If you want
> We already have the information in multiple places. We've used MDC for
> this information for multiple releases now. We also have the
> mozilla.dev.extensions newsgroup. Both of these are "official"
> locations for this information. The new developer hub on AMO is trying
> to combine the two.
The addons site provides a new extension-developer-oriented table of
contents with links into MDC, but it does not point to
mozilla.dev.extensions. Rather it replaces it. This step was not
appreciated by readers of mozilla.dev.extensions.
jjb
Philip Chee
> Argh, we have *another* extension developer forum? That means we now have
> two mozilla-official fora (mozilla.dev.extensions and the new AMO one) and
> the MozillaZine fora, which are awful but refuse to die.
> What was wrong with mozilla.dev.extensions that we needed to create another
> venue?
New->Shiny! Plus probably some element of N.I.H. too.
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.
[ ]Never park your hard disk in a tow-away zone.
* TagZilla 0.066.6
Philip Chee
> I humbly suggest this is a topic for another thread, and in that
> thread, I will humbly suggest that we either kill
> mozilla.dev.extensions or have it be a 1:1 mirror of whatever addons.mozilla.org
> is using.
Won't it be more logical to kill the new forum at AMO and move
everything to m.d.extensions, since m.d.e. is the more established and
better known of the two?
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.
[ ]If "R" is Reverse, how come "D" is FORWARD?
* TagZilla 0.066.6
Philip Chee
> Unless the environment on MozillaZine has changed drastically from the
> past, I don't think that's feasible. That community is far to abusive
> to individuals from Mozilla when they disagree with something Mozilla
> has done.
Despite being an active SeaMonkey developer, mozillazine regulars have
never been abusive at me personally[1] despite on occasion being angry
at certain changes in 2.0. Perhaps you just need to work on your people
skills?
[1] excluding the usual trolls of course who just like to flame anyone
at random.
John O'Duinn
> On 10/21/09 4:20 PM, Simon Paquet wrote:
>
>> Branch maintenance replacement
>> ==============================
>> At this moment, Firefox 3.5 has been out for nearly four months and it
>> will most likely be out for roughly six months when Firefox 3.6 will be
>> released as far as I understand the current release schedule.
>>
>> That will essentially mean, that the 1.9.0 branch will no longer be
>> maintained with security and stability fixes according to the current
>> policy as far as I'm aware. So we're not really talking about
>> "maintaining another branch". We're talking about replacing the
>> maintenance of one older branch (whose first public release will be
>> roughly 18 months old when 3.6 will be released) with the maintenance of
>> a younger branch (whose first public release is just six month old).
>>
>> So releasing 3.6 as a minor update and not supporting 3.5-based release
>> with further security and stability fixes would essentially mean, that
>> you would have to further maintain an 18 month old release (with a much
>> older branch) instead of maintaining a much younger codebase.
>
> No it wouldn't. Whether we do 3.6 as a major or minor update has little
> bearing on whether we continue to support 3.0: the six month clock is
> already ticking and will expire on December 31 either way.
bsmedberg:
I think Simon was saying that this proposal would mean:
Firefox 3.0 EOL: 31Dec2009
Firefox 3.5 EOL: whenever we ship FF3.6, which is *before* 31Dec2009.
...putting us in an unusual state of de-supporting FF3.5 before we
de-support FF3.0.
Simon is that what you meant?
tc
John.
John O'Duinn
Boris Zbarsky wrote:
> On 10/23/09 11:54 AM, John J. Barton wrote:
>> Benjamin Smedberg wrote:
>> ....
>>> Maybe we should default to just making major updates happen without
>>> prompting as long as extensions are fully compatible.
>>
>> Perhaps I am belaboring this point, but in practice determining
>> extension compatibility is an experiment conducted with large numbers of
>> users. That means we need FF 3.6 and FF 3.5 for a overlapping period of
>> time, the time it takes for a large number of users to try the extension
>> while they still have a fall back option. So update 3.5 -> 3.6 without
>> prompts or what ever you like, but give us a window first.
>
> Maybe I misunderstood Benjamin, but it sounded like he was proposing
> that for any given user, if all the extensions _that_particular_user_
> has installed are marked as compatible with the new release then we
> should just do the major update. In the limiting case, if there are no
> extensions installed we should just do the major update.
>
> Benjamin, was that the proposal?
>
> -Boris
aiui, the extension version check happens *after* the user has decided
to upgrade, and has started doing the install.
I dont know of a way to check extension compatibility *before* prompting
user to upgrade.
What am I missing?
tc
John.
Benjamin Smedberg
> aiui, the extension version check happens *after* the user has decided
> to upgrade, and has started doing the install.
>
> I dont know of a way to check extension compatibility *before* prompting
> user to upgrade.
We have control over this entire operation. For major update currently, we
check extension compatibility and warn the user if there is not a new
version for extensions they have enabled. It's dirt-simple to extend it so
that if there are no incompatible extensions we upgrade silently.
--BDS
Robert Strong
compatibility and warn the user if any enabled and compatible extensions
will be disabled by the update as long as the user hasn't changed the
default of "Warn me if this will disable any of my add-ons". In the case
of major updates the user is always notified instead of doing a silent
update.
Robert
John O'Duinn
> I think the model of providing opt-in major and silent minor updates has
> evolved for good reason, which is that those are fundamentally different
> propositions to the end user (and even more so to enterprises).
>
> Silent updates should only reduce risk from a security, stability and
> general usability/compatibility standpoint.
>
> Major updates introduce new attack surface due to new features, and
> present new risks of stability and usability issues due to UI changes,
> features changes or architectural refactoring, but also provide neat new
> things (for users and/or developers) to take advantage of. UI changes
> are not the only criteria for differentiating between a major and minor
> update. For a given user, a major update may or may not be considered
> an actual improvement, depending on their priorities.
>
> And while we never intend a release to ship with major security,
> stability or usability issues, despite the best efforts of mice and men
> we (and everyone else shipping software of such complexity) continue to
> do so. At least for some significant portion of our users.
>
> Part of the story about permitting product-driven updates in enterprises
> is a clear differentiator between updates and new releases. We have had
> some luck with organizations permitting auto-update with Firefox because
> it just sort of works and doesn't introduce functionality issues nor
> does it impact the security implications and assumptions. To blur the
> line between updates and new releases can be a bit regressive as it will
> encourage organizations to disable auto update and certify updates
> manually, which is something most enterprises would dearly like to avoid
> IMHO.
I 100% agree with all of what Lucas said above.
I'm all in favor of actively prompting users to MU; the quicker we get
people to migrate off older, less secure, versions of Firefox, the safer
our user community is.
I just don't like the idea of using a standard minor update prompt to do
this MU.
Like Lucas said above, there is the risk of people hitting something we
missed, despite our best intentions. We then risk people refusing future
security updates because they might some feature might break/change.
Can I suggest an alternate proposal?
Recall that FF3.5 was the first time we had MU available on major
release day. And even then, it was only for users who did
manual-check-for-update.
For Firefox3.6, how about we do prompted, unthrottled, FF3.5->FF3.6 MU
available on FF3.6 release day for *all* users?
This would be a big step forward in terms of user adoption, and is more
clearly explicitly a user choice to upgrade, with clearer expectations
of possible changes in behavior.
> I don't think the majority of our users are that different. People
> switch to Firefox for a lot of reasons but I think chief among them are
> security, performance, customization, functionality and a general
> perception of trust. Even those leading edge users that evangelize the
> latest and greatest browser features I think realize that, when they are
> recommending a browser to their neighbor, friend or relative, that
> individuals goals are less about having the latest CSS support and more
> about general user experience, security, privacy and satisfaction.
>
> If the fundamental problem we are trying to solve is less about
> deploying new features aggressively and more about supporting too many
> releases simultaneously, then that's a problem we should discuss. A
> sliding window model where we support each minor release for some
> smaller amount of time before driving users to the next minor version,
> with a longer support window for each major version, might be an option.
> Lucas.
Yes, supporting too many releases feels like the root of the problem to
me also, tbh.
Given our new faster ability to do faster releases, I think we should
revise our EOL policy to match this new reality. This thread is already
long enough, so I'll spin that question out to another thread.
tc
John.
=====
Gervase Markham
> I think Simon was saying that this proposal would mean:
>
> Firefox 3.0 EOL: 31Dec2009
> Firefox 3.5 EOL: whenever we ship FF3.6, which is *before* 31Dec2009.
>
> ...putting us in an unusual state of de-supporting FF3.5 before we
> de-support FF3.0.
That's not all that unusual; Ubuntu and other Linux distributions, for
example, have particular older releases which stay in support longer
than the intermediate ones have.
However, if say Firefox 3.6 is released at the end of November, it would
put us in the position that, 1 month after release, it would be the
_only_ supported Firefox release, because 3.5 would have been
superceded, and 3.0 would have passed six months.
Taken to the extreme, if Firefox 3.6 slips to the end of December,
everyone would have to upgrade on the same day in order to stay on a
supported version!
Gerv