Schedule for releases

[Robert N. M. Watson]

On 22 Dec 2010, at 01:28, Julian Elischer wrote:

>> (2) Is our security support lifetime for -STABLE branches too short to allow
>>    major products to be built on them and have the downstream product
>>    lifetime largely live within our lifetime?
> 
> I think so.. places I have worked tend to need about a year to get a new release of their
> product out the door in practice, and if we jump to a new  release every year,
> then as they jump, so do we, so they are 2 revisions back "again".
> Generally a company wouldn't want to go through the pain of an OS upgrade more than
> about once in three years and often it's longer..  It IS a pain for them.
> they have to actually retool all their testing and they have to re-certify tons of
> stuff, such as their build procedures. ALSO, with a new release comes a new set of ports.
> and THEY have to be re-certified too.

The extended support release model was introduced to address these specific concerns, providing non-".0" releases that had a guarantee of a minimum of two years security support from the day of release. It would be interesting to know if this has in fact led to a preference for building products and providing services on extended support releases.

Looking at our current supported release table, I see that all but one of the releases on the table is an extended support release, including all non-".0" 7.x releases to date. For example, 7.1-RELEASE was shipped 4 January 2009, and will go out of support on 31 January, 2011. That's not a bad run. And if vendors slide along 7-STABLE, then they'll get two years from the final release of 7.4, likely supporting them through early 2013.

We also now provide binary updates and binary upgrades -- less valuable to appliance builders, but it would appear widely used by service-oriented consumers. Feedback from vendors / consumers who are using extended releases in preference to regular releases would be welcome -- is the current balance there right?

Most of the feedback I'm getting suggests that our policy and technology changes in the last few years, bringing in extended support releases and binary updates, have addressed those problem areas. Instead the concern is more that -STABLE branches wrap up too quickly: if you start building a product against .0, and ship with .1, then you may find yourself trying to continue to support the product several years past our last .x release, causing problems running on contemporary hardware due to stale hardware support. And I worry a lot about the upstream problem: vendors who have significant local changes that never go upstream because HEAD is two major releases ahead.

But I think we need vendors to tell us specific stories about exactly where and how things have gone wrong -- Matthew's post is valuable in that sense, as sometimes we just hear "grumble grumble releases too fast", or "running into device driver problems with 6.x!". I did some work with a customer recently in which it was almost impossible to test the changes we made upstream on their actual product release version on the basis of a lack of device driver support in 6.x, which no longer supports ethernet and storage chipsets on many current motherboards.

Robert