+1 [even if we try to avoid voting ; o)] We are on the same page here, using time-based releases but keeping the develop branch clean and buildable to allow additional releases if needed.
Best, Markus .::YAGNI likes a DRY KISS::. > From: [email protected] > To: [email protected] > Subject: RE: Release cycle 2 months, soak period 2 weeks? > Date: Sat, 9 Jan 2016 04:19:18 +0000 > > +1 > > I meant feature based releases should be possible outside the two month cycle > ;-) > > Sent from my Windows Phone > ________________________________ > From: Greg Stein<mailto:[email protected]> > Sent: 1/8/2016 7:38 AM > To: > [email protected]<mailto:[email protected]> > Subject: Re: Release cycle 2 months, soak period 2 weeks? > > To provide another view: cutting releases "every two months" creates > *activity* which attracts users/developers. Going with a feature-based > release might end up with a long delay [until the feature(s) are done], > which then appears as stagnation. > > We switched to date-based releases in Subversion's early development, and > interest dramatically spiked. We used a metaphor of a "train". If a feature > gets on the train, then great. If not ... no big deal. It will catch the > next train. No need to stress. > > That said, I'll reinforce Ross' statement of keeping the main branch > buildable and useful. That enables a release according to any schedule or > need you'd like. And to get source here, as soon as possible. > > Cheers, > -g > > > On Fri, Jan 8, 2016 at 6:59 AM, Ross Gardler <[email protected]> > wrote: > > > Note, ASF projects will typically release "as required". Setting an > > expected cadence in policy is all fine.what matters is someone does the > > work. > > > > Keeping trunk in an "always releaseable" state is preferable to a promise > > of another release in x months. This means that anyone can cut a release > > and start the process at any time. > > > > Remember, Apache projects only release source code (binaries are only a > > convenience that some projects choose to provide). The goal is to allow > > downstream users more flexibility than an official release cycle documented > > in policy. That is cut a release whenever one is needed rather than when > > someone else in the community decides its time. Remember anyone (committer > > or otherwise) can produce a release candidate and releases cannot be vetoed > > (thigh releases need to be approved by the PPMc). > > > > I'm not trying to put a stop to policy working, but honestly, starting the > > removal of non-compliant licenses will get us to that first release much > > more quickly. > > > > Ross > > > > > > Sent from my Windows Phone > > ________________________________ > > From: Myrle Krantz<mailto:[email protected]> > > Sent: 1/8/2016 9:57 AM > > To: [email protected]<mailto: > > [email protected]> > > Subject: Re: Release cycle 2 months, soak period 2 weeks? > > > > I'm not entirely sure we are talking about the same thing. > > > > As I wrote in the document I sent to start this thread: > > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcwiki.apache.org%2fconfluence%2fdisplay%2fFINERACT%2fRelease%2bManagement&data=01%7c01%7cRoss.Gardler%40microsoft.com%7cbd07f873744844790f8908d318122a65%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ObRmLmfpC6ceQGQZuXCe0ZcOR6kHo1kpInNIMNGom14%3d > > > > "Release branches are created every two months at the beginning of the > > following month from the changes that were merged by the last day of the > > previous month. > > > > If a feature is almost but not quite done at the end of the month, the > > release is not delayed for the feature. That feature goes into the next > > release scheduled for two months later." > > > > > > If we choose to work according to the plan I described, then we would be > > working on a date-driven cadence, at least as I understand it. > > > > Of course we are releasing features and not tool bundles, so we won't make > > a release if there are no changes merged in those two months. If there's > > even one change, I would expect a release. And if that change is finished > > two days after the deadline, I would expect the release to come at the next > > two-monthly release. > > > > Gitlab does something similar, but with a release period of one month: > > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fabout.gitlab.com%2f2015%2f12%2f07%2fwhy-we-shift-objectives-and-not-release-dates-at-gitlab%2f&data=01%7c01%7cRoss.Gardler%40microsoft.com%7cbd07f873744844790f8908d318122a65%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=mPfHddysNWSr5Ny2Mn3WIiNm2l%2blpeZ9%2fBpvZMoKuKs%3d > > > > > > Greets, > > > > Myrle > > > > > > > > > > *Myrle Krantz* > > Solutions Architect > > RɅĐɅЯ, The Mifos Initiative > > [email protected] | Skype: > > https://na01.safelinks.protection.outlook.com/?url=mkrantz.mifos.org&data=01%7c01%7cRoss.Gardler%40microsoft.com%7cbd07f873744844790f8908d318122a65%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=mWTUs0BSMkHgTc1HEjL74ThI91jT79Xnk%2f8WZokmg8U%3d > > | > > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmifos.org&data=01%7c01%7cRoss.Gardler%40microsoft.com%7cbd07f873744844790f8908d318122a65%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=jXa1LqIPVvsHvmrGi6vGEhPMNbisByxEDKxfATf0LQk%3d > > < > > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ffacebook.com%2fmifos&data=01%7c01%7cRoss.Gardler%40microsoft.com%7cbd07f873744844790f8908d318122a65%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2Y1ZdQx35Uymx841zX1J3ckaI2wRihC8APzFYYsPmNc%3d> > > < > > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.twitter.com%2fmifos&data=01%7c01%7cRoss.Gardler%40microsoft.com%7cbd07f873744844790f8908d318122a65%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Ju51bsgXVuYDROgkNLYE7ytn%2b6Q3M6TamHHm6f43qgg%3d > > > > > > > > > On Thu, Jan 7, 2016 at 7:13 PM, Markus Geiss <[email protected]> wrote: > > > > > On 01/07/2016 05:36 PM, Roman Shaposhnik wrote: > > > > > >> On Thu, Jan 7, 2016 at 3:52 AM, Myrle Krantz <[email protected]> wrote: > > >> > > >>> Hi Fin Fans, > > >>> > > >>> To start the conversation on release cycle, I've documented my > > suggestion > > >>> here: > > >>> > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcwiki.apache.org%2fconfluence%2fdisplay%2fFINERACT%2fRelease%2bManagement&data=01%7c01%7cRoss.Gardler%40microsoft.com%7cbd07f873744844790f8908d318122a65%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ObRmLmfpC6ceQGQZuXCe0ZcOR6kHo1kpInNIMNGom14%3d > > >>> > > >>> The additions to what was there before consist of: > > >>> * release cycle length added > > >>> * soak period shortened to better match release cycle length > > >>> > > >> > > >> Would it be possible to spell out your release cadence model more > > >> explicitly? > > >> Is it a date-driven cadence (like Ubuntu, lets say) or a feature-driven > > >> one? > > >> > > >> Thanks, > > >> Roman. > > >> > > >> > > > Given that we are releasing a software product, not a distribution of a > > > certain kind, e.g. Ubuntu, CentOS, Mint, I think a feature-driven > > > model. > > > > > > The development of Fineract will be driven by user requirements, > > > specific to the platform. Bundled libraries will only have influence > > > on the release schedule if a security issue was detected and fixed. > > > > > > Best, > > > > > > Markus > > > > > > .::YAGNI likes a DRY KISS::. > > > > >
