328188 - Need to develop EOL/support policy for old releases, post it, and adhere to it

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: General, defect)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

We need to develop a clear EOL/support policy for how long we will provide security fixes for old versions, both versions which do not drop support for a major OS version and for those which do.

For versions which do not drop support for a major OS version, the policy should be simple: as soon as the new version is out, the old one will no longer receive updates.  The road to 1.0, though, had us go from late April to early November with no security fixes to the 0.8.x branch but no new version at even a "beta" level (Fx did 4 security releases on their 1.0.x branch during that period).

For versions which do drop support for a major OS version (which will be fairly common from here on out), 6 mos or as long as Mo* is doing security updates for that Gecko branch (whichever is shorter), perhaps?  And then X weeks after the last security release/EOL deadline passes (whichever is later), we remove download mention of that version from cb.o.

We don't want to unduly burden ourselves with supporting lots of dead branches, but at the same time we should make clear to our users how long we will provide them security updates.

Comment 1

[Samuel Sidler (old account; do not CC)]

I was thinking about this and came up with the following:

We maintain a stable build on three OS versions at all times and keep support for a fourth for one year after the latest OS version has come out.

As an example, let's say Camino 1.0 is the last version to run on 10.2. We maintain this version, with stability and security updates, for one year after 10.5 comes out. It seems like a long time, but it's basically what we're doing with 10.1/0.8.4 (that'd be April 2006, fwiw). Maybe a year is too long and we could just say "6 month maintenance period, 3 month period on our website, post maintenance", which would mean we deliver updates for six months after 10.5 comes out and keep 1.0 on our website for three months after our last release.

That seems like an acceptable way to keep old OS users stable and secure without maintaining them for too long.

Comment 2

[Mark Mentovai]

(In reply to comment #1)
> We maintain a stable build on three OS versions at all times

This is too dependent on Apple's release schedules.  Let's say that the current stable branch will not drop support for any OS version that was current in the past three years.  This commits Jaguar support in whatever happens to be the current stable branch through October.  (I had hoped for 1.1 before that, but being realistic, it's probably just about right.)

> and keep support
> for a fourth for one year after the latest OS version has come out.

...a (possibly non-current) stable branch will not drop support for any OS version current in the past four years.  This only commits the 0.8/1.7 branch to live until August.

Also, as you mentioned in a different way in comment 0, we need to say that support is dependent on core support - unless we can get similar guarantees out of the core too.

And "this policy is subject to change."

And what does it all mean anyway?  We explicitly disclaim everything we can.  We're not commmitted to providing support.  If we wanted to, we could pack up and shut down tomorrow.  And even if we didn't, enough other devs could throw in the towel to make it impossible to continue.  I think this is all a bunch of masturbation.

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I don't like Sam's idea at all; it's too limiting and commits us to too much for too long.  I just wanted a fairly simple statement to help people know when we're going to cut them off security-wise if they don't upgrade their OS, as well as something that guides when we stop listing builds for old OSes on the websiste, and something that keeps us more honest with security updates when there's no new stable build (iow, the 7 months between 0.8.4 and 1.0b1 when we did no security updates for our users and Mo* did 4 security releases!).  In this age of increases security consciousness, I think attentiveness to these issues are a key part of being a credible browser provider.

1. For new stable major releases that do not drop support for a major Mac OS X version, the version being replaced is immediately unsupported (in terms of new security point releases) and is immediately removed from listing on cb.o in favor of the new release. [1.2 will do this to 1.1]

2. In the absence of a new stable major release (we can define this however we want; it seems we've used "beta or higher" recently), we provide security updates to the previous stable branch every ca. 2 months, as warranted, and as long as Mo* is still maintaing that branch for security purposes. [1.1.x until 1.2]

3. When a new stable major release drops support for a major Mac OS X version, we will continue to provide security point releases on that branch for no longer than N months (6 is the max I'd consider) every ca. 2 months, as warranted, provided Mo* is still maintaing that branch for security purposes.  After N months, we remove download mention of this version from cb.o. [1.0.x for N months after 1.1]

I really don't care so much about the length of time in point 3; it can be 0 as far as I'm concerned.  The truly important thing, and what I don't want to see us do, is continue to list ("recommend") a version for download that has known unpatched security holes just because it supports an OS version that our current builds do not.

(In my scenario, if 1.1 comes out in April, we'll continue to release 1.0.x security point updates (for 10.2 users) until October (if we do 6 mos. and Mo* maintains the 1.8.0 branch until then).  Until 1.2 comes out, we'll release 1.1.x security point updates every 2 months as warranted, then cease when 1.2 arrives.)

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I'm almost ready to WONTFIX this now (after adding a few notes to the wiki first).  We've been vigilant since then, and we've avoided the "7 month with no security updates to stable builds" scenario all through the 1.0.x cycle (the 3 month gaps between the last few 1.0.x were a tiny bit ugly, but livable).  We're essentially doing what I proposed in the last comment.

The only thing I'd like to see clarified is at what point we stop "promoting" 1.0.6. Right now, if you visit the home page, cbo/start (and soon welcome) in 1.0.x, we suggest 1.0.x users upgrade to 1.5, or if on 10.2, the latest 1.0.x.  

At what point after 1.0.6 ships do we want to stop prompting 1.0.x users to upgrade to 1.0.6--or is it always preferable for 1.0.x users to be pushed to use 1.0.6, even 6 months after we've stopped shipping security updates?  Do we continue to show it until 2.0 is out and we need to use the "down-rev OS version message" for pushing the last 1.6.x updates for 10.3 users?