You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Sebastien Goasguen <ru...@gmail.com> on 2013/03/04 11:34:41 UTC
Re: [DISCUSS] Support lifetime
On Feb 28, 2013, at 1:21 PM, Joe Brockmeier <jz...@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 ?
>> - 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) ?
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.
>>
>> 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
>
> Best,
>
> jzb
> --
> Joe Brockmeier
> jzb@zonker.net
> Twitter: @jzb
> http://www.dissociatedpress.net/
Re: [DISCUSS] Support lifetime
Posted by Joe Brockmeier <jz...@zonker.net>.
On Tue, Mar 5, 2013, at 04:55 AM, Prasanna Santhanam wrote:
> The 4.0.1-incubating release only had one database change
> (91a9cce35a67350c856bb10e5fe36f4bf5bac029) so it's probably a good
> time to decide on a strategy for upgrades from the 4.0.x line to the
> 4.x-5.0 line.
That particular issue might benefit from a separate thread, since it's
something that needs to be discussed regardless of what support timeline
we decide on.
Best,
jzb
--
Joe Brockmeier
jzb@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/
Re: [DISCUSS] Support lifetime
Posted by Rohit Yadav <bh...@apache.org>.
In minor CloudStack version we OUGHT NOT change the DB schema, maybe
we should not even change the DB version, comment?
So, all minor version should have version info in DB as 4.0 (for 4.0,
4.0.1 and 4.0.2) and 4.1 (possible future 4.1.xs) etc.
Regards.
On Tue, Mar 5, 2013 at 4:25 PM, Prasanna Santhanam <ts...@apache.org> wrote:
> On Mon, Mar 04, 2013 at 09:53:36AM -0500, Chip Childers wrote:
>> On Mon, Mar 04, 2013 at 05:34:41AM -0500, Sebastien Goasguen wrote:
>> >
>> > On Feb 28, 2013, at 1:21 PM, Joe Brockmeier <jz...@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.
>>
>
> The context of upgrades came up on IRC today - it looks like the 4.0.x
> line is still using the old method of doing upgrades ie w.o.
> DatabaseCreator. So if at some point the 4.0.x line alters schema
> upgrading that deployment is going to run into problems because it
> doesn't conform to the dbCreator's way of doing things.
>
> The 4.0.1-incubating release only had one database change
> (91a9cce35a67350c856bb10e5fe36f4bf5bac029) so it's probably a good
> time to decide on a strategy for upgrades from the 4.0.x line to the
> 4.x-5.0 line.
>
> --
> Prasanna.,
Re: [DISCUSS] Support lifetime
Posted by Prasanna Santhanam <ts...@apache.org>.
On Mon, Mar 04, 2013 at 09:53:36AM -0500, Chip Childers wrote:
> On Mon, Mar 04, 2013 at 05:34:41AM -0500, Sebastien Goasguen wrote:
> >
> > On Feb 28, 2013, at 1:21 PM, Joe Brockmeier <jz...@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.
>
The context of upgrades came up on IRC today - it looks like the 4.0.x
line is still using the old method of doing upgrades ie w.o.
DatabaseCreator. So if at some point the 4.0.x line alters schema
upgrading that deployment is going to run into problems because it
doesn't conform to the dbCreator's way of doing things.
The 4.0.1-incubating release only had one database change
(91a9cce35a67350c856bb10e5fe36f4bf5bac029) so it's probably a good
time to decide on a strategy for upgrades from the 4.0.x line to the
4.x-5.0 line.
--
Prasanna.,
Re: [DISCUSS] Support lifetime
Posted by Chip Childers <ch...@sungard.com>.
On Mon, Mar 04, 2013 at 10:59:49AM -0600, Joe Brockmeier wrote:
> On Mon, Mar 4, 2013, at 09:03 AM, David Nalley wrote:
> > 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)
>
> Does it matter if we're ending support for 4.0.x if the users can
> reliably upgrade to 4.2.x and we're sticking to a no API breakage
> policy?
IMO, that was the reason that I suggested it the way I did. Perhaps we
consider security updates for the last X feature releases, but bug fixes
(non-security) are (again IMO) probably OK being limited to the last
feature release.
>
> Note that a policy saying that we will support (say) 4.2 and 5.0
> wouldn't preclude also pushing out a security fix for 4.1 and 4.0 if it
> was not overly difficult to backport the security fix.
Right
>
> The biggest concerns I have are: 1) finding people to address bugs in
> older releases and 2) testing the releases - so I'd like to be
> conservative in what we promise, but there's no reason we can't
> over-deliver if we see a security issue that needs to be addressed.
Those are my exact same concerns.
>
> Best,
>
> jzb
> --
> Joe Brockmeier
> jzb@zonker.net
> Twitter: @jzb
> http://www.dissociatedpress.net/
>
Re: [DISCUSS] Support lifetime
Posted by Joe Brockmeier <jz...@zonker.net>.
On Mon, Mar 4, 2013, at 09:03 AM, David Nalley wrote:
> 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)
Does it matter if we're ending support for 4.0.x if the users can
reliably upgrade to 4.2.x and we're sticking to a no API breakage
policy?
Note that a policy saying that we will support (say) 4.2 and 5.0
wouldn't preclude also pushing out a security fix for 4.1 and 4.0 if it
was not overly difficult to backport the security fix.
The biggest concerns I have are: 1) finding people to address bugs in
older releases and 2) testing the releases - so I'd like to be
conservative in what we promise, but there's no reason we can't
over-deliver if we see a security issue that needs to be addressed.
Best,
jzb
--
Joe Brockmeier
jzb@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/
Re: [DISCUSS] Support lifetime
Posted by Chip Childers <ch...@sungard.com>.
On Tue, Mar 05, 2013 at 04:36:10AM -0500, Sebastien Goasguen wrote:
>
> On Mar 4, 2013, at 11:17 AM, "Musayev, Ilya" <im...@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 <ch...@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 <jz...@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.
Re: [DISCUSS] Support lifetime
Posted by Sebastien Goasguen <ru...@gmail.com>.
On Mar 4, 2013, at 11:17 AM, "Musayev, Ilya" <im...@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 <ch...@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 <jz...@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
RE: [DISCUSS] Support lifetime
Posted by "Musayev, Ilya" <im...@webmd.net>.
> -----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 <ch...@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 <jz...@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.
RE: [DISCUSS] Support lifetime
Posted by "Musayev, Ilya" <im...@webmd.net>.
-----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 <ch...@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 <jz...@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?
Re: [DISCUSS] Support lifetime
Posted by Chip Childers <ch...@sungard.com>.
On Mon, Mar 04, 2013 at 10:03:51AM -0500, David Nalley wrote:
> 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)
So for bugfixes, I'm going to stick to my guns with the proposal.
Semver is our friend, as long as we use it correctly. We should
encourage upgrades as we move along with new features.
As for security fixes, I'd be ok with adding some amount of time-based
expectation to the overall process.
Re: [DISCUSS] Support lifetime
Posted by David Nalley <da...@gnsa.us>.
On Mon, Mar 4, 2013 at 9:53 AM, Chip Childers <ch...@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 <jz...@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
Re: [DISCUSS] Support lifetime
Posted by Chip Childers <ch...@sungard.com>.
On Mon, Mar 04, 2013 at 05:34:41AM -0500, Sebastien Goasguen wrote:
>
> On Feb 28, 2013, at 1:21 PM, Joe Brockmeier <jz...@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
> >
> > Best,
> >
> > jzb
> > --
> > Joe Brockmeier
> > jzb@zonker.net
> > Twitter: @jzb
> > http://www.dissociatedpress.net/
>
>