Re: Upcoming Releases Schedule...


On Wed, 17 Sep 2008, Jo Rhett wrote:

On Mon, 15 Sep 2008, Jo Rhett wrote:
Robert, I'd like to point out to you that when I complained about 6.2's accelerated EoL, I was soundly boxed around the ears and told that I should have been paying attention to the projected EoL date when we decided to roll out 6.2 across the business.

Now you are saying that expected EoL will be determined at some random point in the future based on gut feelings about how well a completely different branch is doing.

How can I reconcile these disparate points of view? How does one focus on testing and upgrade cycle for an "appropriately supported release" when the decision for the support cycle is completely up in the air?

On Sep 16, 2008, at 12:47 PM, Robert Watson wrote:
The FreeBSD Project, as with any other company or organization, responds to events as they occur. We try to plan ahead, and when things go better or worse than expected, we sometimes change the plans. As far as I know we've never *shortened* the expected support timeline for any branch or release, but we have on occasion lenthened them when we feel it's important to do so. I'm not sure what other answer is possible.

No other answer. But nobody has yet provided what the EoL period is going to be. I have no problems with a period being extended ;-) But the business needs to know the minimum EoL for a given release to determine if upgrading to that release is viable.

Well, a starting answer is the policy found on http://security.FreeBSD.org/:

Early adopter
Releases which are published from the -CURRENT branch will be supported by
the Security Officer for a minimum of 6 months after the release.

Normal
Releases which are published from a -STABLE branch will be supported by the
Security Officer for a minimum of 12 months after the release.

Extended
Selected releases will be supported by the Security Officer for a minimum of
24 months after the release.

At the time of release, we know if a release is considered "early adopter", and attempt to clearly mark it as such. The harder question is whether or not we will start out considering a release "normal" or "extended" -- sometimes we are able to make that decision at the time of the release (i.e., we believe firmly it's the last release on the branch at the time of release), but on the whole we will make that decision based on the facts on the ground.

An important factor is whether or not we consider the release a highly maintainable release, and while we have intuitions at the time of release, that's something we can only learn in the first couple of months after it's in production. I don't know of any COTS software house that really does it any differently, and I'm not sure you could do it differently -- no one plans to ship a lemon, but once in a while you discover that things don't go as planned.

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-stable@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Security Officer-supported branches update
    ... The branches supported by the FreeBSD Security Officer have been ... but I have extended the EoL date ... extenuating circumstances would lead to a branch's support being ...
    (FreeBSD-Security)
  • Re: challenge: end of life for 6.2 is premature with buggy 6.3
    ... and then observe the EoL get pushed. ... I'm sorry that the FreeBSD project failed to conform to your ... release picked by the team to be support for,.. ... the attitude and opinion you have right now accomplishes nothing other than alienating your supporters. ...
    (freebsd-stable)
  • Re: challenge: end of life for 6.2 is premature with buggy 6.3
    ... and then observe the EoL get pushed. ... I'm sorry that the FreeBSD project failed to conform to your ... release picked by the team to be support for,.. ... The OP stated there are unclosed bugs that be believes are preventing him from using 6.3 and called into question the decision of EoL'ing 6.2. ...
    (freebsd-stable)
  • FreeBSD supported branches update
    ... The branches supported by the FreeBSD Security Officer have been updated ... to reflect the EoL of FreeBSD 7.0. ... that FreeBSD 7.2-RELEASE will only receive "normal" support (i.e., ...
    (FreeBSD-Security)
  • FreeBSD supported branches update
    ... The branches supported by the FreeBSD Security Officer have been updated ... to reflect the EoL of FreeBSD 7.0. ... that FreeBSD 7.2-RELEASE will only receive "normal" support (i.e., ...
    (freebsd-stable)