Just pulled up the link: https://cwiki.apache.org/confluence/display/FINERACT/Versioning
On Sun, Jan 10, 2016 at 12:53 AM, Greg Stein <[email protected]> wrote: > 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::. >> > > > > >> > > > >> > >> > >> > >
