cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <da...@gnsa.us>
Subject Re: [DISCUSS] Support lifetime
Date Mon, 04 Mar 2013 15:03:51 GMT
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

Mime
View raw message