I understand the difficulties involved in dropping older releases. I'm voicing my opinion from the perspective of what is sustainable for our team (long tail of QA for updates, support, etc) gives users depending on a "certified" platform long enough notice to plan migrations to the newer software.
Perhaps my proposal could be clarified to include: "Dropped" versions will still be made available for users that need them, but support will be limited to community engagement. Matt Ingenthron said this cool thing on 8/27/07 16:02: > Hi all, > > On this topic, I thought it may make sense to point back to an earlier > SFWNV thread... > > Joe McCabe wrote: >> Re: 2.x minor version cohabitation >> >> I think we should allow one minor revision back along with "tip" minor >> version cohabitation (i.e. 2.2.x & 2.4.x), but with a clear >> termination point on the older version. Some kind of policy like: >> >> The older minor release will be maintained in a deprecated state for >> 18 months from the time of integration of the newer minor release. >> After 18 months cohabitation and support of the older release will be >> dropped, and no new updates will be integrated. >> > Reading this thread reminds me of this older thread on SFWNV: > http://www.opensolaris.org/jive/thread.jspa?messageID=102968𙈸 > > With some of these things, it'd be very, very hard to say you'll drop > the old ABI/API. In any case, we're really following the upstream and > what customers do with it, and they may want us to maintain multiple > ABIs for a long period of time*. Or drop an intermediate release or two > and have an "old popular" and "new popular" version integrated. Further, > we can't make assumptions about what various numbers mean between the > dots on API and ABI stability. Specifically, note that APR and httpd > take different meanings from x.y.z. > > Another thread worth reading is this one: > http://www.opensolaris.org/jive/thread.jspa?messageID=104674 > > It's a long read, but a lot of good thought went into it and it may help > us avoid some future issues. Unfortunately, there's no good summary of > where we ended up to my knowledge, but maybe it's clear to the rest of > the team actually working on the integration. > > - Matt > > * This is analagous to what ISVs do with Solaris in a way-- they still > support Solaris 8 because they have customer demand for it-- we may need > to support Apache 1.3 for a long time due to demand-- not because either > we or apache think it's the best approach >
