On Tue, Mar 05, 2013 at 04:36:10AM -0500, Sebastien Goasguen wrote: > > On Mar 4, 2013, at 11:17 AM, "Musayev, Ilya" <imusa...@webmd.net> wrote: > > > > > > >> -----Original Message----- > >> From: Musayev, Ilya [mailto:imusa...@webmd.net] > >> Sent: Monday, March 04, 2013 11:05 AM > >> To: cloudstack-dev@incubator.apache.org > >> Subject: RE: [DISCUSS] Support lifetime > >> > >> > >> > >> -----Original Message----- > >> From: David Nalley [mailto:da...@gnsa.us] > >> Sent: Monday, March 04, 2013 10:04 AM > >> To: cloudstack-dev@incubator.apache.org > >> Subject: Re: [DISCUSS] Support lifetime > >> > >> On Mon, Mar 4, 2013 at 9:53 AM, Chip Childers <chip.child...@sungard.com> > >> wrote: > >>> On Mon, Mar 04, 2013 at 05:34:41AM -0500, Sebastien Goasguen wrote: > >>>> > >>>> On Feb 28, 2013, at 1:21 PM, Joe Brockmeier <j...@zonker.net> wrote: > >>>> > >>>>> On Wed, Feb 27, 2013, at 03:00 PM, Chip Childers wrote: > >>>>>> I stated my opinion on this previously [1], but for the record again: > >>>>>> > >>>>>> I would suggest that we only do bug-fix releases for: > >>>>>> > >>>>>> - The latest feature release of our active major version number (i.e.: > >>>>>> 4.x) > >>>> > >>>> To make sure I get this right: > >>>> > >>>> So Once we release 4.2 we will only bug fix 4.1 and stop bug fixing 4.0 ? > >>> > >>> That's what I'm proposing, yes. > >>> > >>>> > >>>>>> - The latest feature release of our last major version number > >>>>>> (doesn't exist today, but will be 4.x when / if we bump to 5.0) > >>>> > >>>> Once we jump to 5.X we will bug fix the latest 4.x release (if it's 4.2, > >>>> we > >> will stop bug fixing 4.1) ? > >>>> > >>> > >>> That's also what I'm proposing, yup. > >>> > >>>> The really crucial part for me is to make sure we have a really > >>>> solid/tested > >> upgrade path. We cannot leave anyone out in the cold of a "unsupported" > >> release. > >>>> > >>> > >>> Indeed. Upgrades remain critical to this project. We need to > >>> constantly ensure that we have upgrade paths available from any > >>> version to the latest version. > >>> > >>>>>> > >>>>>> Just my opinion though. Others? > >>>>>> > >>>>>> [1] http://markmail.org/message/quzgjne44prl5m2c > >>>>> > >>>>> Given the current levels of participation on dot-releases, I think > >>>>> this is the most realistic approach that's good for the community. > >>>>> > >>>>> +1 > >>>>> > >> > >> > >>> So software typically has several stages: > >> > >>> Does end of support mean both of these things simultaneously. > >>> No more bugfixes > >>> No more security fixes > >> > >>> So wearing your enterprise software consumer hat - does a support > >>> lifetime of approximately 12 months make sense? (not saying it > >>> doesn't, just asking the question) Under the above proposal we'd end > >>> support for the 4.0 line after 4.2 releases. (I'd personally say we > > >>> should add a month (so that EOL is one month after 4.n+2 releases, > >>> with the understanding that 4.n is likely to only receive security > >>> fixes if any during that extra one month window) > >> > >>> --David > >> > >> I think a 12 month support is reasonable for bug fixes and security > >> patches. > >> Now if we adhere to a release schedule of 4 months, we will have 3 new > >> releases every year, within 24 month cycle, there is going to be 6 > >> versions of > >> CloudStack to either release or maintain. > >> > >> Does anyone else besides myself thinks it's a little too much to handle? > >> > > > > > > If I do the math right, 34 (not 36) months from now, we are going to > > maintain 9 versions of cloudstack. > > Forward looking, it gets complicated. We release 3 versions per year, and > > yet only 1 rolls off the support. > > > > Ilya has a good point here, maintaining 9 releases seems like a lot > > >
I'm against 12 months of support for all feature branches. Primarily, I'm concerned with the effort required. Secondarily, I feel that if we maintain upgrade paths and we stick to the *spirit* (which is greater than the word) of semver, then we leave users in a reasonable position.
