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
