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" <[email protected]> To: <[email protected]> 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" <[email protected]> > To: <[email protected]> > 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 <[email protected]> >> 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" <[email protected]> >>> To: <[email protected]> >>> 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 >>>> >> >> >
