The release numbering is primarily based on the description/rules described at semver.org, rather than dates.
On Sat, Jan 9, 2016 at 11:28 PM, Terence Monteiro < [email protected]> wrote: > +1. > > I believe releases should be both time bound and incorporate what Markus > calls "user driven features". Assuming we have consensus on the (punctual) > train based model, I would propose using signed tags for releases and also > numbering releases based on the YYYY.mm model (not sure if I'm repeating > what's already somewhere in the wiki). My rationale is release automation > is easier and multi-platform and uses git's inherent cmdline tools to get > the release number from the tag itself and also have verifiable method for > a partner or source code downloader authenticating the major release source > code. On *nix I can simply say `date "+%Y.%m"` and use it in a shell script > for instance to generate packages more easily. Think bin/make-release.sh > (and maybe bin/make-release.bat) under the project root folder for > instance. > > -- > Best Regards, > Terence Monteiro, > Mob: +91 96633 13728 > > > www.sanjosesolutions.in > "Providence", No. 36, > Ahmed Sait Road, > Frazer Town, Bangalore - 5. > > On Sat, Jan 9, 2016 at 7:56 PM, Ross Gardler <[email protected]> > wrote: > > > Cool. > > > > Note, +1 is just an explicit shorthand for "I agree and will help to > merge > > it happen", it does happen to be the same shorthand were use in voting, > but > > it's not voting. > > > > Other common shorthand is: > > > > +0 sounds good but I can't help directly > > > > -0 I'm not convinced but I have no alternative to offer so if you want yo > > do it that way, fine > > > > -1 I think that would be a mistake because ... Here's my alternative > > approach ... > > > > Of course it's not an exact science, just a shorthand intended to help > > gage community support for a proposal. > > > > The last one is important. It indicates a lack of consensus and the > > alternative approach should be discussed further. Ask the others are just > > shorthand. > > > > Sent from my Windows Phone > > ________________________________ > > From: Markus Geiß<mailto:[email protected]> > > Sent: 1/9/2016 4:12 AM > > To: [email protected]<mailto: > > [email protected]> > > Subject: RE: Release cycle 2 months, soak period 2 weeks? > > > > +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::. > > > > > > > > > > > > > >
