How do we update from Firefox 3.5 to 3.6?

7 views
Skip to first unread message

Axel Hecht

unread,
Oct 15, 2009, 8:05:01 PM10/15/09
to
Hi,

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

unread,
Oct 21, 2009, 12:12:26 AM10/21/09
to dev-pl...@lists.mozilla.org
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.

cheers,
mike

John J. Barton

unread,
Oct 21, 2009, 1:18:33 AM10/21/09
to
Mike Beltzner wrote:
...

> 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

unread,
Oct 21, 2009, 6:36:55 AM10/21/09
to Mike Beltzner, dev-pl...@lists.mozilla.org
hi;

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

unread,
Oct 21, 2009, 6:50:37 AM10/21/09
to Mike Beltzner, dev-pl...@lists.mozilla.org
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.

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

unread,
Oct 21, 2009, 10:11:08 AM10/21/09
to
I'd like to re-raise another concern, and that's product availability
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

unread,
Oct 21, 2009, 10:36:56 AM10/21/09
to Mike Beltzner, dev-pl...@lists.mozilla.org
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.
>
All the above is really good analysis. On the last point I'll agree
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

unread,
Oct 21, 2009, 11:24:39 AM10/21/09
to
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.

Robert Kaiser

Robert Kaiser

unread,
Oct 21, 2009, 11:29:34 AM10/21/09
to
John O'Duinn wrote:
> 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

unread,
Oct 21, 2009, 11:45:35 AM10/21/09
to
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.
...

> // 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

unread,
Oct 21, 2009, 11:50:36 AM10/21/09
to jod...@mozilla.com, dev-pl...@lists.mozilla.org
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.

> -- 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

unread,
Oct 21, 2009, 11:52:27 AM10/21/09
to time...@gmail.com, dev-pl...@lists.mozilla.org
On 2009-10-21, at 6:50 AM, timeless wrote:

> 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

unread,
Oct 21, 2009, 11:52:43 AM10/21/09
to John J. Barton, dev-pl...@lists.mozilla.org
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?

> 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

unread,
Oct 21, 2009, 11:52:47 AM10/21/09
to Robert Kaiser, dev-pl...@lists.mozilla.org

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

unread,
Oct 21, 2009, 12:00:36 PM10/21/09
to
On 10/21/09 11:52 AM, Mike Beltzner wrote:
> 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

unread,
Oct 21, 2009, 12:01:29 PM10/21/09
to
On 10/21/09 11:52 AM, Mike Beltzner wrote:

> 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

unread,
Oct 21, 2009, 12:14:51 PM10/21/09
to
On 10/21/09 1:18 AM, John J. Barton wrote:

> 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

unread,
Oct 21, 2009, 12:20:10 PM10/21/09
to
On 10/21/09 11:29 AM, Robert Kaiser wrote:

> 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

unread,
Oct 21, 2009, 12:39:56 PM10/21/09
to
Mike Beltzner wrote:
> 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

unread,
Oct 21, 2009, 1:51:08 PM10/21/09
to Mike Beltzner, dev-pl...@lists.mozilla.org, Robert Kaiser
Mike Beltzner wrote:
> On 2009-10-21, at 11:24 AM, Robert Kaiser wrote:
>
> 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),

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

unread,
Oct 21, 2009, 2:00:38 PM10/21/09
to Mike Beltzner, dev-pl...@lists.mozilla.org

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

unread,
Oct 21, 2009, 3:30:49 PM10/21/09
to
Mike Beltzner wrote:
> 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

unread,
Oct 21, 2009, 3:36:59 PM10/21/09
to dev-pl...@lists.mozilla.org
On 10/21/09 12:30 PM, Robert Kaiser wrote:
> 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.
That was added back in before the beta.

/sdwilsh

Robert Kaiser

unread,
Oct 21, 2009, 3:37:37 PM10/21/09
to

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

unread,
Oct 21, 2009, 3:59:26 PM10/21/09
to
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.

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

unread,
Oct 21, 2009, 4:34:34 PM10/21/09
to Mike Beltzner, dev-pl...@lists.mozilla.org
On Wed, Oct 21, 2009 at 6:52 PM, Mike Beltzner <belt...@mozilla.com> wrote:
> 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? :)

Message has been deleted

Robert Kaiser

unread,
Oct 21, 2009, 5:13:40 PM10/21/09
to

For all platforms or only for Mac? I thought it was just the latter...

Robert Kaiser

Robert Kaiser

unread,
Oct 21, 2009, 5:14:52 PM10/21/09
to
Benjamin Smedberg wrote:
> 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

unread,
Oct 21, 2009, 5:36:33 PM10/21/09
to Benjamin Smedberg, dev-pl...@lists.mozilla.org
On 10/21/09 12:59 PM, Benjamin Smedberg wrote:
> 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

unread,
Oct 21, 2009, 5:45:55 PM10/21/09
to
Le 21. 10. 09 20:00, John O'Duinn a �crit :

>> 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

unread,
Oct 21, 2009, 7:16:35 PM10/21/09
to
On 10/21/2009 12:12 AM, Mike Beltzner wrote:
> 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.

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

unread,
Oct 21, 2009, 7:26:29 PM10/21/09
to
Can we make Firefox 3.6 be an unprompted minor update (like in
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

unread,
Oct 21, 2009, 8:05:06 PM10/21/09
to

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

unread,
Oct 21, 2009, 10:18:57 PM10/21/09
to dev-pl...@lists.mozilla.org
On 10/21/09 4: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
> 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.
Isn't that assuming that we'd release 3.6 as a minor update the same
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

unread,
Oct 21, 2009, 11:18:23 PM10/21/09
to
On 10/21/2009 10:18 PM, Shawn Wilsher wrote:
>> 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

unread,
Oct 22, 2009, 12:43:48 AM10/22/09
to dev-pl...@lists.mozilla.org
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 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

unread,
Oct 22, 2009, 5:19:28 AM10/22/09
to
On 22/10/09 05:43, Lucas Adamski wrote:
> 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

unread,
Oct 22, 2009, 8:48:07 AM10/22/09
to
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).

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

unread,
Oct 22, 2009, 8:48:52 AM10/22/09
to

What are the technical reasons you can't? This sounds like something that
can be solved pretty easily.

--BDS

chris hofmann

unread,
Oct 22, 2009, 9:44:59 AM10/22/09
to Benjamin Smedberg, 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

Axel Hecht

unread,
Oct 22, 2009, 11:04:59 AM10/22/09
to

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

unread,
Oct 22, 2009, 11:13:24 AM10/22/09
to Axel Hecht, dev-pl...@lists.mozilla.org
I think it is north of 95% for the pretty long tail of most used addons

https://wiki.mozilla.org/WeeklyUpdates/2009-07-27#Add-ons

> Axel

Shawn Wilsher

unread,
Oct 22, 2009, 11:14:54 AM10/22/09
to dev-pl...@lists.mozilla.org
On 10/22/09 5:48 AM, Benjamin Smedberg wrote:
> What are the technical reasons you can't? This sounds like something that
> can be solved pretty easily.
The download manager dropped support for importing data in from
downloads.rdf in 1.9.2.

Cheers,

Shawn

Shawn Wilsher

unread,
Oct 22, 2009, 11:17:29 AM10/22/09
to dev-pl...@lists.mozilla.org
On 10/22/09 6:44 AM, chris hofmann wrote:
> that translates into much cat herding still to be done
And don't we tend to see that percentage go up once we release a beta,
which we haven't done yet?

Cheers,

Shawn

John J. Barton

unread,
Oct 22, 2009, 12:05:59 PM10/22/09
to
Benjamin Smedberg wrote:
> 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

unread,
Oct 22, 2009, 11:51:11 AM10/22/09
to Shawn Wilsher, dev-pl...@lists.mozilla.org

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

unread,
Oct 22, 2009, 12:13:03 PM10/22/09
to chof...@meer.net, benj...@smedbergs.us, dev-pl...@lists.mozilla.org
Hi all,

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

unread,
Oct 22, 2009, 12:38:43 PM10/22/09
to

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

unread,
Oct 22, 2009, 4:29:18 PM10/22/09
to
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.

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

unread,
Oct 22, 2009, 4:56:07 PM10/22/09
to
Daniel Veditz wrote:
> 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

unread,
Oct 23, 2009, 9:07:21 AM10/23/09
to
On 10/22/09 12:05 PM, John J. Barton wrote:

> 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

unread,
Oct 23, 2009, 9:08:00 AM10/23/09
to

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

unread,
Oct 23, 2009, 9:12:04 AM10/23/09
to
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.

> 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

unread,
Oct 23, 2009, 9:22:17 AM10/23/09
to
On 10/22/09 12:43 AM, Lucas Adamski wrote:
> 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

unread,
Oct 23, 2009, 10:18:30 AM10/23/09
to Benjamin Smedberg, dev-pl...@lists.mozilla.org
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.

> 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

unread,
Oct 23, 2009, 10:39:32 AM10/23/09
to

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

unread,
Oct 23, 2009, 10:46:08 AM10/23/09
to Benjamin Smedberg, dev-pl...@lists.mozilla.org
If we take that kind of approach we are all in agreement.

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