incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: [DISCUSS] Support lifetime
Date Thu, 07 Mar 2013 16:35:21 GMT
On Tue, Mar 05, 2013 at 04:36:10AM -0500, Sebastien Goasguen wrote:
> 
> On Mar 4, 2013, at 11:17 AM, "Musayev, Ilya" <imusayev@webmd.net> wrote:
> 
> > 
> > 
> >> -----Original Message-----
> >> From: Musayev, Ilya [mailto:imusayev@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:david@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.childers@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 <jzb@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.

Mime
View raw message