Via Pete Zaitcev I just read FreeBSD and release engineering (lwn.net), which is about some issues people are having with the FreeBSD release schedules. That article will probably be a Rorschach test for at least non-FreeBSD people, because how you react to the ideas in it will probably depend on how you see 'production support'. Before I get into my reactions to it (in another entry), I've decided to write down how I see production support.

To me:

• Full support of a production OS release means that it gets bugfixes, security fixes, and support for new hardware; the latter is necessary so that you can actually install it on new servers and machines that you can or want to buy today.

• Legacy support of a production OS release means security fixes and major bugfixes, but you no longer need to update it for new hardware or fix smaller bugs. That it will not necessarily install and run on current-generation hardware is what makes it 'legacy'.

  (Ie legacy support is to keep already-installed machines running, not to let you keep installing new machines.)

There should be some overlap in full support between release X and release X+1, because people are not necessarily ready to start installing new machines with release X+1 the moment it comes out.

A production release should not change the code of existing features and systems beyond genuine bug fixes and security updates (and for new hardware support if you really, really have to do so). I really do mean 'the code of', not just 'the behavior of', because any code change adds the possibility of bugs and incompatibilities. I don't trust OS vendors to not accidentally introduce either of these in code changes, so I want code changes minimized as much as possible.

I don't mind if a production release (in either full support or legacy support) gets genuinely new features and software provided that those features are optional and are written in such a way that there is no possibility that they will change or destabilize systems that do not use them. For example, if you want to add iSCSI target support as some new programs and a new loadable kernel module, knock yourself out and I don't care. But if your new iSCSI target driver requires changes to general kernel code, no, forget it; that's too dangerous.

(Another way to put this is that new features are analogous to new hardware support, except that unlike new hardware support you don't get to change anything that already exists. If you can't add it without changing existing things, you don't get to add it at all.)

I don't think that you should allow optional replacement of existing software with new software versions (eg, an optional upgrade from Apache 1.x to Apache 2.x) because it creates a combinatorial explosion in significant variations on the initial production OS release. Among other issues, you can easily get into a situation where no one actually really supports running the original Apache 1.x version any more because everyone has made the 'optional' upgrade to Apache 2.x, which effectively makes the upgrade mandatory instead.

(The extreme version of this is how Debian stable and unstable used to be, where practically no one in the Debian development community actually used the stable version any more.)