[PROPOSAL] New way for releases scheduling

[Jacques Le Roux <ja...@les7arts.com>]

Hi,

For some days now, I was thinking about a "new way of releasing" (only schedule related). I thought about it while looking by chance at release strategies of few other Apache projects. Notably how they plan things...

Today, a reminder poped up for the "End of month: Main New Features" mail I send every end of month. I believe there were not much, if any, main new features last month, but it reminded me about the ideas I had on releases scheduling. 

My proposition is to not release each year but every 2 or, preferred, 3 years. Here are the reasons:

1) There are less and less new features, so there are less needs to distribute often (ie every year)
2) Security and bug fixes can still be done with new minor releases
3) Users can still grab new features they want from trunk as long as they are well documented in main new feature page (maybe we should add there the revs #)


PROS:
* This has the obvious advantage of removing some release burden (mostly done by Jacopo these days, thanks to him)
* But not only, it's also easier for users. Because moving from one release to the other each year is not very easy for a project. For some project it takes sometimes a year, if not more, to stabilize. And moving from an older release is even harder (see for instance recent Skip's from 9 to 12 experience)
* If they want new stuff they can always use trunk. I believe people are now more interested in stability and security than new features; because OFBiz is mature.
* We will more follow how most Apache projects evolve (most don't do major releases each year). And it should be easier to plan things (something we really lack, something users can refer to), like some other Apache projects do.
* Since we decided to let alive only the 3 last releases, this would greatly increase the  releases life span...
* Because we decided to remove specialpurpose from releases, new components should not be a problem (this suppose no new applications level components, but anyway read below about this convention)

CONS:
* Less features each year, need to wait more for that, but anyway still availabe from trunk

I can't see anything else, I must miss some CONS points :).

What do you think? Of course this would not be set  in stone. If a major new feature needs to be released, the convention could be left aside for a new major release.

Jacques

Re: [PROPOSAL] New way for releases scheduling

[Ruth Hoffman <rh...@aesolves.com>]

Hi Jacques:
For what it is worth: Best OFBiz proposal I've heard in a long time!
Ruth
On 8/6/13 9:02 AM, Jacques Le Roux wrote:
> Hi,
>
> For some days now, I was thinking about a "new way of releasing" (only schedule related). I thought about it while looking by chance at release strategies of few other Apache projects. Notably how they plan things...
>
> Today, a reminder poped up for the "End of month: Main New Features" mail I send every end of month. I believe there were not much, if any, main new features last month, but it reminded me about the ideas I had on releases scheduling.
>
> My proposition is to not release each year but every 2 or, preferred, 3 years. Here are the reasons:
>
> 1) There are less and less new features, so there are less needs to distribute often (ie every year)
> 2) Security and bug fixes can still be done with new minor releases
> 3) Users can still grab new features they want from trunk as long as they are well documented in main new feature page (maybe we should add there the revs #)
>
>
> PROS:
> * This has the obvious advantage of removing some release burden (mostly done by Jacopo these days, thanks to him)
> * But not only, it's also easier for users. Because moving from one release to the other each year is not very easy for a project. For some project it takes sometimes a year, if not more, to stabilize. And moving from an older release is even harder (see for instance recent Skip's from 9 to 12 experience)
> * If they want new stuff they can always use trunk. I believe people are now more interested in stability and security than new features; because OFBiz is mature.
> * We will more follow how most Apache projects evolve (most don't do major releases each year). And it should be easier to plan things (something we really lack, something users can refer to), like some other Apache projects do.
> * Since we decided to let alive only the 3 last releases, this would greatly increase the  releases life span...
> * Because we decided to remove specialpurpose from releases, new components should not be a problem (this suppose no new applications level components, but anyway read below about this convention)
>
> CONS:
> * Less features each year, need to wait more for that, but anyway still availabe from trunk
>
> I can't see anything else, I must miss some CONS points :).
>
> What do you think? Of course this would not be set  in stone. If a major new feature needs to be released, the convention could be left aside for a new major release.
>
> Jacques
>

Re: [PROPOSAL] New way for releases scheduling

[Jacques Le Roux <ja...@les7arts.com>]

Mmm... dont misunserstand me, of course if in 1 year there is/are major/s new (unplanned) feature/s then releasing will make sense. Sincerely, due to the declining activity, I don't expect such thing, but of course... as ever, you never know...

Jacques


----- Original Message ----- 
From: "Jacques Le Roux" <ja...@les7arts.com>
To: <de...@ofbiz.apache.org>
Sent: Tuesday, August 13, 2013 10:32 AM
Subject: Re: [PROPOSAL] New way for releases scheduling


> This sounds wise to me, indeed we can't really envisoin what we will have in 1 year, unless we try to plan something, even roughly. For instance something like the slim down action, which I believe is done now, right?
> 
> Jacques
> 
> ----- Original Message ----- 
> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
> To: <de...@ofbiz.apache.org>
> Sent: Tuesday, August 13, 2013 9:40 AM
> Subject: Re: [PROPOSAL] New way for releases scheduling
> 
> 
>> Until now the creation of a release branch every year made sense and the 09.04, 10.04, 11.04, 12.04 and 13.07 look very different ones from each other.
>> Sometime during the Spring-Summer of 2014 we could compare the trunk with the 13.07 release branch and decide what to do; if they don't look very different we could check again in 6-12 months or so.
>> In short, I agree with the idea that a release branch should be created only if it is significantly different from the previous one (and this has been always true till now); however I think that a yearly check to see if a release branch should be created is a good thing, if it doesn't imply that we have to create a branch each year.
>> 
>> Regards,
>> 
>> Jacopo
>> 
>> On Aug 9, 2013, at 4:14 PM, Jacques Le Roux <ja...@les7arts.com> wrote:
>> 
>>> It seems we are all almost on the same page. I will wait a bit more for other opinions, vacations time...
>>> 
>>> Jacques
>>> 
>>> ----- Original Message ----- 
>>> From: "Adrian Crum" <ad...@sandglass-software.com>
>>> To: <de...@ofbiz.apache.org>
>>> Sent: Wednesday, August 07, 2013 4:31 PM
>>> Subject: Re: [PROPOSAL] New way for releases scheduling
>>> 
>>> 
>>>> Thanks Scott. I agree with you.
>>>> 
>>>> -Adrian
>>>> 
>>>> On 8/6/2013 6:53 PM, Scott Gray wrote:
>>>>> My opinion is that we should release whenever we (the community) feel the features added since the last release warrant it.  There's no point in making releases if they add little value on the previous and there's no point in waiting some arbitrary amount of time before releasing good features.
>>>>> 
>>>>> User's aren't obligated to upgrade every year just because we release something.  It only ever makes sense if the release holds more value to them than the cost of upgrading.  So at a minimum an upgrade would only be needed every 3 years (and only if the user didn't have the resources to manually backport security/stability fixes) based on the current release schedule.
>>>>> 
>>>>> In general though I agree we could increase our maximum wait between major releases to something more than a year.
>>>>> 
>>>>> Regards
>>>>> Scott
>>>>> 
>>>>> On 7/08/2013, at 1:02 AM, Jacques Le Roux wrote:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> For some days now, I was thinking about a "new way of releasing" (only schedule related). I thought about it while looking by chance at release strategies of few other Apache projects. Notably how they plan things...
>>>>>> 
>>>>>> Today, a reminder poped up for the "End of month: Main New Features" mail I send every end of month. I believe there were not much, if any, main new features last month, but it reminded me about the ideas I had on releases scheduling.
>>>>>> 
>>>>>> My proposition is to not release each year but every 2 or, preferred, 3 years. Here are the reasons:
>>>>>> 
>>>>>> 1) There are less and less new features, so there are less needs to distribute often (ie every year)
>>>>>> 2) Security and bug fixes can still be done with new minor releases
>>>>>> 3) Users can still grab new features they want from trunk as long as they are well documented in main new feature page (maybe we should add there the revs #)
>>>>>> 
>>>>>> 
>>>>>> PROS:
>>>>>> * This has the obvious advantage of removing some release burden (mostly done by Jacopo these days, thanks to him)
>>>>>> * But not only, it's also easier for users. Because moving from one release to the other each year is not very easy for a project. For some project it takes sometimes a year, if not more, to stabilize. And moving from an older release is even harder (see for instance recent Skip's from 9 to 12 experience)
>>>>>> * If they want new stuff they can always use trunk. I believe people are now more interested in stability and security than new features; because OFBiz is mature.
>>>>>> * We will more follow how most Apache projects evolve (most don't do major releases each year). And it should be easier to plan things (something we really lack, something users can refer to), like some other Apache projects do.
>>>>>> * Since we decided to let alive only the 3 last releases, this would greatly increase the  releases life span...
>>>>>> * Because we decided to remove specialpurpose from releases, new components should not be a problem (this suppose no new applications level components, but anyway read below about this convention)
>>>>>> 
>>>>>> CONS:
>>>>>> * Less features each year, need to wait more for that, but anyway still availabe from trunk
>>>>>> 
>>>>>> I can't see anything else, I must miss some CONS points :).
>>>>>> 
>>>>>> What do you think? Of course this would not be set  in stone. If a major new feature needs to be released, the convention could be left aside for a new major release.
>>>>>> 
>>>>>> Jacques
>>>> 
>> 
>>
>

Re: [PROPOSAL] New way for releases scheduling

[Jacques Le Roux <ja...@les7arts.com>]

This sounds wise to me, indeed we can't really envisoin what we will have in 1 year, unless we try to plan something, even roughly. For instance something like the slim down action, which I believe is done now, right?

Jacques

----- Original Message ----- 
From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
To: <de...@ofbiz.apache.org>
Sent: Tuesday, August 13, 2013 9:40 AM
Subject: Re: [PROPOSAL] New way for releases scheduling


> Until now the creation of a release branch every year made sense and the 09.04, 10.04, 11.04, 12.04 and 13.07 look very different ones from each other.
> Sometime during the Spring-Summer of 2014 we could compare the trunk with the 13.07 release branch and decide what to do; if they don't look very different we could check again in 6-12 months or so.
> In short, I agree with the idea that a release branch should be created only if it is significantly different from the previous one (and this has been always true till now); however I think that a yearly check to see if a release branch should be created is a good thing, if it doesn't imply that we have to create a branch each year.
> 
> Regards,
> 
> Jacopo
> 
> On Aug 9, 2013, at 4:14 PM, Jacques Le Roux <ja...@les7arts.com> wrote:
> 
>> It seems we are all almost on the same page. I will wait a bit more for other opinions, vacations time...
>> 
>> Jacques
>> 
>> ----- Original Message ----- 
>> From: "Adrian Crum" <ad...@sandglass-software.com>
>> To: <de...@ofbiz.apache.org>
>> Sent: Wednesday, August 07, 2013 4:31 PM
>> Subject: Re: [PROPOSAL] New way for releases scheduling
>> 
>> 
>>> Thanks Scott. I agree with you.
>>> 
>>> -Adrian
>>> 
>>> On 8/6/2013 6:53 PM, Scott Gray wrote:
>>>> My opinion is that we should release whenever we (the community) feel the features added since the last release warrant it.  There's no point in making releases if they add little value on the previous and there's no point in waiting some arbitrary amount of time before releasing good features.
>>>> 
>>>> User's aren't obligated to upgrade every year just because we release something.  It only ever makes sense if the release holds more value to them than the cost of upgrading.  So at a minimum an upgrade would only be needed every 3 years (and only if the user didn't have the resources to manually backport security/stability fixes) based on the current release schedule.
>>>> 
>>>> In general though I agree we could increase our maximum wait between major releases to something more than a year.
>>>> 
>>>> Regards
>>>> Scott
>>>> 
>>>> On 7/08/2013, at 1:02 AM, Jacques Le Roux wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> For some days now, I was thinking about a "new way of releasing" (only schedule related). I thought about it while looking by chance at release strategies of few other Apache projects. Notably how they plan things...
>>>>> 
>>>>> Today, a reminder poped up for the "End of month: Main New Features" mail I send every end of month. I believe there were not much, if any, main new features last month, but it reminded me about the ideas I had on releases scheduling.
>>>>> 
>>>>> My proposition is to not release each year but every 2 or, preferred, 3 years. Here are the reasons:
>>>>> 
>>>>> 1) There are less and less new features, so there are less needs to distribute often (ie every year)
>>>>> 2) Security and bug fixes can still be done with new minor releases
>>>>> 3) Users can still grab new features they want from trunk as long as they are well documented in main new feature page (maybe we should add there the revs #)
>>>>> 
>>>>> 
>>>>> PROS:
>>>>> * This has the obvious advantage of removing some release burden (mostly done by Jacopo these days, thanks to him)
>>>>> * But not only, it's also easier for users. Because moving from one release to the other each year is not very easy for a project. For some project it takes sometimes a year, if not more, to stabilize. And moving from an older release is even harder (see for instance recent Skip's from 9 to 12 experience)
>>>>> * If they want new stuff they can always use trunk. I believe people are now more interested in stability and security than new features; because OFBiz is mature.
>>>>> * We will more follow how most Apache projects evolve (most don't do major releases each year). And it should be easier to plan things (something we really lack, something users can refer to), like some other Apache projects do.
>>>>> * Since we decided to let alive only the 3 last releases, this would greatly increase the  releases life span...
>>>>> * Because we decided to remove specialpurpose from releases, new components should not be a problem (this suppose no new applications level components, but anyway read below about this convention)
>>>>> 
>>>>> CONS:
>>>>> * Less features each year, need to wait more for that, but anyway still availabe from trunk
>>>>> 
>>>>> I can't see anything else, I must miss some CONS points :).
>>>>> 
>>>>> What do you think? Of course this would not be set  in stone. If a major new feature needs to be released, the convention could be left aside for a new major release.
>>>>> 
>>>>> Jacques
>>> 
> 
>

Re: [PROPOSAL] New way for releases scheduling

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

Until now the creation of a release branch every year made sense and the 09.04, 10.04, 11.04, 12.04 and 13.07 look very different ones from each other.
Sometime during the Spring-Summer of 2014 we could compare the trunk with the 13.07 release branch and decide what to do; if they don't look very different we could check again in 6-12 months or so.
In short, I agree with the idea that a release branch should be created only if it is significantly different from the previous one (and this has been always true till now); however I think that a yearly check to see if a release branch should be created is a good thing, if it doesn't imply that we have to create a branch each year.

Regards,

Jacopo

On Aug 9, 2013, at 4:14 PM, Jacques Le Roux <ja...@les7arts.com> wrote:

> It seems we are all almost on the same page. I will wait a bit more for other opinions, vacations time...
> 
> Jacques
> 
> ----- Original Message ----- 
> From: "Adrian Crum" <ad...@sandglass-software.com>
> To: <de...@ofbiz.apache.org>
> Sent: Wednesday, August 07, 2013 4:31 PM
> Subject: Re: [PROPOSAL] New way for releases scheduling
> 
> 
>> Thanks Scott. I agree with you.
>> 
>> -Adrian
>> 
>> On 8/6/2013 6:53 PM, Scott Gray wrote:
>>> My opinion is that we should release whenever we (the community) feel the features added since the last release warrant it.  There's no point in making releases if they add little value on the previous and there's no point in waiting some arbitrary amount of time before releasing good features.
>>> 
>>> User's aren't obligated to upgrade every year just because we release something.  It only ever makes sense if the release holds more value to them than the cost of upgrading.  So at a minimum an upgrade would only be needed every 3 years (and only if the user didn't have the resources to manually backport security/stability fixes) based on the current release schedule.
>>> 
>>> In general though I agree we could increase our maximum wait between major releases to something more than a year.
>>> 
>>> Regards
>>> Scott
>>> 
>>> On 7/08/2013, at 1:02 AM, Jacques Le Roux wrote:
>>> 
>>>> Hi,
>>>> 
>>>> For some days now, I was thinking about a "new way of releasing" (only schedule related). I thought about it while looking by chance at release strategies of few other Apache projects. Notably how they plan things...
>>>> 
>>>> Today, a reminder poped up for the "End of month: Main New Features" mail I send every end of month. I believe there were not much, if any, main new features last month, but it reminded me about the ideas I had on releases scheduling.
>>>> 
>>>> My proposition is to not release each year but every 2 or, preferred, 3 years. Here are the reasons:
>>>> 
>>>> 1) There are less and less new features, so there are less needs to distribute often (ie every year)
>>>> 2) Security and bug fixes can still be done with new minor releases
>>>> 3) Users can still grab new features they want from trunk as long as they are well documented in main new feature page (maybe we should add there the revs #)
>>>> 
>>>> 
>>>> PROS:
>>>> * This has the obvious advantage of removing some release burden (mostly done by Jacopo these days, thanks to him)
>>>> * But not only, it's also easier for users. Because moving from one release to the other each year is not very easy for a project. For some project it takes sometimes a year, if not more, to stabilize. And moving from an older release is even harder (see for instance recent Skip's from 9 to 12 experience)
>>>> * If they want new stuff they can always use trunk. I believe people are now more interested in stability and security than new features; because OFBiz is mature.
>>>> * We will more follow how most Apache projects evolve (most don't do major releases each year). And it should be easier to plan things (something we really lack, something users can refer to), like some other Apache projects do.
>>>> * Since we decided to let alive only the 3 last releases, this would greatly increase the  releases life span...
>>>> * Because we decided to remove specialpurpose from releases, new components should not be a problem (this suppose no new applications level components, but anyway read below about this convention)
>>>> 
>>>> CONS:
>>>> * Less features each year, need to wait more for that, but anyway still availabe from trunk
>>>> 
>>>> I can't see anything else, I must miss some CONS points :).
>>>> 
>>>> What do you think? Of course this would not be set  in stone. If a major new feature needs to be released, the convention could be left aside for a new major release.
>>>> 
>>>> Jacques
>> 

Re: [PROPOSAL] New way for releases scheduling

[Jacques Le Roux <ja...@les7arts.com>]

It seems we are all almost on the same page. I will wait a bit more for other opinions, vacations time...

Jacques

----- Original Message ----- 
From: "Adrian Crum" <ad...@sandglass-software.com>
To: <de...@ofbiz.apache.org>
Sent: Wednesday, August 07, 2013 4:31 PM
Subject: Re: [PROPOSAL] New way for releases scheduling


> Thanks Scott. I agree with you.
> 
> -Adrian
> 
> On 8/6/2013 6:53 PM, Scott Gray wrote:
>> My opinion is that we should release whenever we (the community) feel the features added since the last release warrant it.  There's no point in making releases if they add little value on the previous and there's no point in waiting some arbitrary amount of time before releasing good features.
>>
>> User's aren't obligated to upgrade every year just because we release something.  It only ever makes sense if the release holds more value to them than the cost of upgrading.  So at a minimum an upgrade would only be needed every 3 years (and only if the user didn't have the resources to manually backport security/stability fixes) based on the current release schedule.
>>
>> In general though I agree we could increase our maximum wait between major releases to something more than a year.
>>
>> Regards
>> Scott
>>
>> On 7/08/2013, at 1:02 AM, Jacques Le Roux wrote:
>>
>>> Hi,
>>>
>>> For some days now, I was thinking about a "new way of releasing" (only schedule related). I thought about it while looking by chance at release strategies of few other Apache projects. Notably how they plan things...
>>>
>>> Today, a reminder poped up for the "End of month: Main New Features" mail I send every end of month. I believe there were not much, if any, main new features last month, but it reminded me about the ideas I had on releases scheduling.
>>>
>>> My proposition is to not release each year but every 2 or, preferred, 3 years. Here are the reasons:
>>>
>>> 1) There are less and less new features, so there are less needs to distribute often (ie every year)
>>> 2) Security and bug fixes can still be done with new minor releases
>>> 3) Users can still grab new features they want from trunk as long as they are well documented in main new feature page (maybe we should add there the revs #)
>>>
>>>
>>> PROS:
>>> * This has the obvious advantage of removing some release burden (mostly done by Jacopo these days, thanks to him)
>>> * But not only, it's also easier for users. Because moving from one release to the other each year is not very easy for a project. For some project it takes sometimes a year, if not more, to stabilize. And moving from an older release is even harder (see for instance recent Skip's from 9 to 12 experience)
>>> * If they want new stuff they can always use trunk. I believe people are now more interested in stability and security than new features; because OFBiz is mature.
>>> * We will more follow how most Apache projects evolve (most don't do major releases each year). And it should be easier to plan things (something we really lack, something users can refer to), like some other Apache projects do.
>>> * Since we decided to let alive only the 3 last releases, this would greatly increase the  releases life span...
>>> * Because we decided to remove specialpurpose from releases, new components should not be a problem (this suppose no new applications level components, but anyway read below about this convention)
>>>
>>> CONS:
>>> * Less features each year, need to wait more for that, but anyway still availabe from trunk
>>>
>>> I can't see anything else, I must miss some CONS points :).
>>>
>>> What do you think? Of course this would not be set  in stone. If a major new feature needs to be released, the convention could be left aside for a new major release.
>>>
>>> Jacques
>

Re: [PROPOSAL] New way for releases scheduling

[Jacques Le Roux <ja...@les7arts.com>]

Yes Paul,

That's kinda what I mean too

Jacques

----- Original Message ----- 
From: "Paul Piper" <pp...@ilscipio.com>
To: <de...@ofbiz.apache.org>
Sent: Wednesday, August 07, 2013 5:56 PM
Subject: Re: [PROPOSAL] New way for releases scheduling


> Thanks for bringing this up, jacques. 
> 
> I would have to agree with Scott. Our current mechhanism doesn't really work
> well with open source development. There simply is no way that we can do
> releases each year and schedule subreleases for certain months, hence the
> 12.04, 13.04 habbit seems redundant. 
> 
> I would propose to rather stick with 12.04 as a release now and plan on a
> common goalset for a proper 13th or 12.xxth release. That would make it
> easier to work towards a shared goal as well.
> 
> 
> 
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/PROPOSAL-New-way-for-releases-scheduling-tp4643238p4643254.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: [PROPOSAL] New way for releases scheduling

[Paul Piper <pp...@ilscipio.com>]

Thanks for bringing this up, jacques. 

I would have to agree with Scott. Our current mechhanism doesn't really work
well with open source development. There simply is no way that we can do
releases each year and schedule subreleases for certain months, hence the
12.04, 13.04 habbit seems redundant. 

I would propose to rather stick with 12.04 as a release now and plan on a
common goalset for a proper 13th or 12.xxth release. That would make it
easier to work towards a shared goal as well.



--
View this message in context: http://ofbiz.135035.n4.nabble.com/PROPOSAL-New-way-for-releases-scheduling-tp4643238p4643254.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: [PROPOSAL] New way for releases scheduling

[Adrian Crum <ad...@sandglass-software.com>]

Thanks Scott. I agree with you.

-Adrian

On 8/6/2013 6:53 PM, Scott Gray wrote:
> My opinion is that we should release whenever we (the community) feel the features added since the last release warrant it.  There's no point in making releases if they add little value on the previous and there's no point in waiting some arbitrary amount of time before releasing good features.
>
> User's aren't obligated to upgrade every year just because we release something.  It only ever makes sense if the release holds more value to them than the cost of upgrading.  So at a minimum an upgrade would only be needed every 3 years (and only if the user didn't have the resources to manually backport security/stability fixes) based on the current release schedule.
>
> In general though I agree we could increase our maximum wait between major releases to something more than a year.
>
> Regards
> Scott
>
> On 7/08/2013, at 1:02 AM, Jacques Le Roux wrote:
>
>> Hi,
>>
>> For some days now, I was thinking about a "new way of releasing" (only schedule related). I thought about it while looking by chance at release strategies of few other Apache projects. Notably how they plan things...
>>
>> Today, a reminder poped up for the "End of month: Main New Features" mail I send every end of month. I believe there were not much, if any, main new features last month, but it reminded me about the ideas I had on releases scheduling.
>>
>> My proposition is to not release each year but every 2 or, preferred, 3 years. Here are the reasons:
>>
>> 1) There are less and less new features, so there are less needs to distribute often (ie every year)
>> 2) Security and bug fixes can still be done with new minor releases
>> 3) Users can still grab new features they want from trunk as long as they are well documented in main new feature page (maybe we should add there the revs #)
>>
>>
>> PROS:
>> * This has the obvious advantage of removing some release burden (mostly done by Jacopo these days, thanks to him)
>> * But not only, it's also easier for users. Because moving from one release to the other each year is not very easy for a project. For some project it takes sometimes a year, if not more, to stabilize. And moving from an older release is even harder (see for instance recent Skip's from 9 to 12 experience)
>> * If they want new stuff they can always use trunk. I believe people are now more interested in stability and security than new features; because OFBiz is mature.
>> * We will more follow how most Apache projects evolve (most don't do major releases each year). And it should be easier to plan things (something we really lack, something users can refer to), like some other Apache projects do.
>> * Since we decided to let alive only the 3 last releases, this would greatly increase the  releases life span...
>> * Because we decided to remove specialpurpose from releases, new components should not be a problem (this suppose no new applications level components, but anyway read below about this convention)
>>
>> CONS:
>> * Less features each year, need to wait more for that, but anyway still availabe from trunk
>>
>> I can't see anything else, I must miss some CONS points :).
>>
>> What do you think? Of course this would not be set  in stone. If a major new feature needs to be released, the convention could be left aside for a new major release.
>>
>> Jacques

Re: [PROPOSAL] New way for releases scheduling

[Scott Gray <sc...@hotwaxmedia.com>]

My opinion is that we should release whenever we (the community) feel the features added since the last release warrant it.  There's no point in making releases if they add little value on the previous and there's no point in waiting some arbitrary amount of time before releasing good features.

User's aren't obligated to upgrade every year just because we release something.  It only ever makes sense if the release holds more value to them than the cost of upgrading.  So at a minimum an upgrade would only be needed every 3 years (and only if the user didn't have the resources to manually backport security/stability fixes) based on the current release schedule.

In general though I agree we could increase our maximum wait between major releases to something more than a year.

Regards
Scott

On 7/08/2013, at 1:02 AM, Jacques Le Roux wrote:

> Hi,
> 
> For some days now, I was thinking about a "new way of releasing" (only schedule related). I thought about it while looking by chance at release strategies of few other Apache projects. Notably how they plan things...
> 
> Today, a reminder poped up for the "End of month: Main New Features" mail I send every end of month. I believe there were not much, if any, main new features last month, but it reminded me about the ideas I had on releases scheduling. 
> 
> My proposition is to not release each year but every 2 or, preferred, 3 years. Here are the reasons:
> 
> 1) There are less and less new features, so there are less needs to distribute often (ie every year)
> 2) Security and bug fixes can still be done with new minor releases
> 3) Users can still grab new features they want from trunk as long as they are well documented in main new feature page (maybe we should add there the revs #)
> 
> 
> PROS:
> * This has the obvious advantage of removing some release burden (mostly done by Jacopo these days, thanks to him)
> * But not only, it's also easier for users. Because moving from one release to the other each year is not very easy for a project. For some project it takes sometimes a year, if not more, to stabilize. And moving from an older release is even harder (see for instance recent Skip's from 9 to 12 experience)
> * If they want new stuff they can always use trunk. I believe people are now more interested in stability and security than new features; because OFBiz is mature.
> * We will more follow how most Apache projects evolve (most don't do major releases each year). And it should be easier to plan things (something we really lack, something users can refer to), like some other Apache projects do.
> * Since we decided to let alive only the 3 last releases, this would greatly increase the  releases life span...
> * Because we decided to remove specialpurpose from releases, new components should not be a problem (this suppose no new applications level components, but anyway read below about this convention)
> 
> CONS:
> * Less features each year, need to wait more for that, but anyway still availabe from trunk
> 
> I can't see anything else, I must miss some CONS points :).
> 
> What do you think? Of course this would not be set  in stone. If a major new feature needs to be released, the convention could be left aside for a new major release.
> 
> Jacques