You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by Myrle Krantz <mk...@mifos.org> on 2016/01/07 12:52:03 UTC
Release cycle 2 months, soak period 2 weeks?
Hi Fin Fans,
To start the conversation on release cycle, I've documented my suggestion
here:
https://cwiki.apache.org/confluence/display/FINERACT/Release+Management
The additions to what was there before consist of:
* release cycle length added
* soak period shortened to better match release cycle length
All ideas/opinions are welcome.
Greets from Germany,
*Myrle Krantz*
Solutions Architect
RɅĐɅЯ, The Mifos Initiative
mkrantz@mifos.org | Skype: mkrantz.mifos.org | http://mifos.org
<http://facebook.com/mifos> <http://www.twitter.com/mifos>
Re: Release cycle 2 months, soak period 2 weeks?
Posted by Greg Stein <gs...@gmail.com>.
Just pulled up the link:
https://cwiki.apache.org/confluence/display/FINERACT/Versioning
On Sun, Jan 10, 2016 at 12:53 AM, Greg Stein <gs...@gmail.com> 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 <
> terence@sanjosesolutions.in> 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 <Ro...@microsoft.com>
>> 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ß<ma...@live.de>
>> > Sent: 1/9/2016 4:12 AM
>> > To: dev@fineract.incubator.apache.org<mailto:
>> > dev@fineract.incubator.apache.org>
>> > 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: Ross.Gardler@microsoft.com
>> > > To: dev@fineract.incubator.apache.org
>> > > 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<ma...@gmail.com>
>> > > Sent: 1/8/2016 7:38 AM
>> > > To: dev@fineract.incubator.apache.org<mailto:
>> > dev@fineract.incubator.apache.org>
>> > > 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 <
>> Ross.Gardler@microsoft.com
>> > >
>> > > 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<ma...@mifos.org>
>> > > > Sent: 1/8/2016 9:57 AM
>> > > > To: dev@fineract.incubator.apache.org<mailto:
>> > > > dev@fineract.incubator.apache.org>
>> > > > 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
>> > > > mkrantz@mifos.org | 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 <ma...@live.de>
>> > wrote:
>> > > >
>> > > > > On 01/07/2016 05:36 PM, Roman Shaposhnik wrote:
>> > > > >
>> > > > >> On Thu, Jan 7, 2016 at 3:52 AM, Myrle Krantz <mk...@mifos.org>
>> > 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::.
>> > > > >
>> > > >
>> >
>> >
>>
>
>
Re: Release cycle 2 months, soak period 2 weeks?
Posted by Greg Stein <gs...@gmail.com>.
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 <
terence@sanjosesolutions.in> 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 <Ro...@microsoft.com>
> 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ß<ma...@live.de>
> > Sent: 1/9/2016 4:12 AM
> > To: dev@fineract.incubator.apache.org<mailto:
> > dev@fineract.incubator.apache.org>
> > 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: Ross.Gardler@microsoft.com
> > > To: dev@fineract.incubator.apache.org
> > > 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<ma...@gmail.com>
> > > Sent: 1/8/2016 7:38 AM
> > > To: dev@fineract.incubator.apache.org<mailto:
> > dev@fineract.incubator.apache.org>
> > > 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 <
> Ross.Gardler@microsoft.com
> > >
> > > 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<ma...@mifos.org>
> > > > Sent: 1/8/2016 9:57 AM
> > > > To: dev@fineract.incubator.apache.org<mailto:
> > > > dev@fineract.incubator.apache.org>
> > > > 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
> > > > mkrantz@mifos.org | 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 <ma...@live.de>
> > wrote:
> > > >
> > > > > On 01/07/2016 05:36 PM, Roman Shaposhnik wrote:
> > > > >
> > > > >> On Thu, Jan 7, 2016 at 3:52 AM, Myrle Krantz <mk...@mifos.org>
> > 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::.
> > > > >
> > > >
> >
> >
>
Re: Release cycle 2 months, soak period 2 weeks?
Posted by Terence Monteiro <te...@sanjosesolutions.in>.
+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 <Ro...@microsoft.com>
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ß<ma...@live.de>
> Sent: 1/9/2016 4:12 AM
> To: dev@fineract.incubator.apache.org<mailto:
> dev@fineract.incubator.apache.org>
> 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: Ross.Gardler@microsoft.com
> > To: dev@fineract.incubator.apache.org
> > 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<ma...@gmail.com>
> > Sent: 1/8/2016 7:38 AM
> > To: dev@fineract.incubator.apache.org<mailto:
> dev@fineract.incubator.apache.org>
> > 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 <Ross.Gardler@microsoft.com
> >
> > 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<ma...@mifos.org>
> > > Sent: 1/8/2016 9:57 AM
> > > To: dev@fineract.incubator.apache.org<mailto:
> > > dev@fineract.incubator.apache.org>
> > > 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
> > > mkrantz@mifos.org | 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 <ma...@live.de>
> wrote:
> > >
> > > > On 01/07/2016 05:36 PM, Roman Shaposhnik wrote:
> > > >
> > > >> On Thu, Jan 7, 2016 at 3:52 AM, Myrle Krantz <mk...@mifos.org>
> 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::.
> > > >
> > >
>
>
RE: Release cycle 2 months, soak period 2 weeks?
Posted by Ross Gardler <Ro...@microsoft.com>.
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ß<ma...@live.de>
Sent: 1/9/2016 4:12 AM
To: dev@fineract.incubator.apache.org<ma...@fineract.incubator.apache.org>
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: Ross.Gardler@microsoft.com
> To: dev@fineract.incubator.apache.org
> 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<ma...@gmail.com>
> Sent: 1/8/2016 7:38 AM
> To: dev@fineract.incubator.apache.org<ma...@fineract.incubator.apache.org>
> 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 <Ro...@microsoft.com>
> 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<ma...@mifos.org>
> > Sent: 1/8/2016 9:57 AM
> > To: dev@fineract.incubator.apache.org<mailto:
> > dev@fineract.incubator.apache.org>
> > 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
> > mkrantz@mifos.org | 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 <ma...@live.de> wrote:
> >
> > > On 01/07/2016 05:36 PM, Roman Shaposhnik wrote:
> > >
> > >> On Thu, Jan 7, 2016 at 3:52 AM, Myrle Krantz <mk...@mifos.org> 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::.
> > >
> >
RE: Release cycle 2 months, soak period 2 weeks?
Posted by Markus Geiß <ma...@live.de>.
+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: Ross.Gardler@microsoft.com
> To: dev@fineract.incubator.apache.org
> 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<ma...@gmail.com>
> Sent: 1/8/2016 7:38 AM
> To: dev@fineract.incubator.apache.org<ma...@fineract.incubator.apache.org>
> 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 <Ro...@microsoft.com>
> 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<ma...@mifos.org>
> > Sent: 1/8/2016 9:57 AM
> > To: dev@fineract.incubator.apache.org<mailto:
> > dev@fineract.incubator.apache.org>
> > 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
> > mkrantz@mifos.org | 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 <ma...@live.de> wrote:
> >
> > > On 01/07/2016 05:36 PM, Roman Shaposhnik wrote:
> > >
> > >> On Thu, Jan 7, 2016 at 3:52 AM, Myrle Krantz <mk...@mifos.org> 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::.
> > >
> >
RE: Release cycle 2 months, soak period 2 weeks?
Posted by Ross Gardler <Ro...@microsoft.com>.
+1
I meant feature based releases should be possible outside the two month cycle ;-)
Sent from my Windows Phone
________________________________
From: Greg Stein<ma...@gmail.com>
Sent: 1/8/2016 7:38 AM
To: dev@fineract.incubator.apache.org<ma...@fineract.incubator.apache.org>
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 <Ro...@microsoft.com>
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<ma...@mifos.org>
> Sent: 1/8/2016 9:57 AM
> To: dev@fineract.incubator.apache.org<mailto:
> dev@fineract.incubator.apache.org>
> 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
> mkrantz@mifos.org | 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 <ma...@live.de> wrote:
>
> > On 01/07/2016 05:36 PM, Roman Shaposhnik wrote:
> >
> >> On Thu, Jan 7, 2016 at 3:52 AM, Myrle Krantz <mk...@mifos.org> 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::.
> >
>
Re: Release cycle 2 months, soak period 2 weeks?
Posted by Greg Stein <gs...@gmail.com>.
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 <Ro...@microsoft.com>
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<ma...@mifos.org>
> Sent: 1/8/2016 9:57 AM
> To: dev@fineract.incubator.apache.org<mailto:
> dev@fineract.incubator.apache.org>
> 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
> mkrantz@mifos.org | 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 <ma...@live.de> wrote:
>
> > On 01/07/2016 05:36 PM, Roman Shaposhnik wrote:
> >
> >> On Thu, Jan 7, 2016 at 3:52 AM, Myrle Krantz <mk...@mifos.org> 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::.
> >
>
RE: Release cycle 2 months, soak period 2 weeks?
Posted by Ross Gardler <Ro...@microsoft.com>.
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<ma...@mifos.org>
Sent: 1/8/2016 9:57 AM
To: dev@fineract.incubator.apache.org<ma...@fineract.incubator.apache.org>
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
mkrantz@mifos.org | 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 <ma...@live.de> wrote:
> On 01/07/2016 05:36 PM, Roman Shaposhnik wrote:
>
>> On Thu, Jan 7, 2016 at 3:52 AM, Myrle Krantz <mk...@mifos.org> 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::.
>
Re: Release cycle 2 months, soak period 2 weeks?
Posted by Markus Geiss <ma...@live.de>.
Thanks for the clarification.
We are talking about the same thing here, simply interpreting
terms differently.
I like to introduce another term, used by GitLab, times-based
released, because I think this is the clearest term we can use
for the proposed process.
We will create a release every two month with all feature
branches that were merged into the develop branch prior
to the creation of the release branch. That is my understanding.
Best,
Markus
.::YAGNI likes a DRY KISS::.
On 01/08/2016 10:57 AM, Myrle Krantz wrote:
> 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://cwiki.apache.org/confluence/display/FINERACT/Release+Management
>
> "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://about.gitlab.com/2015/12/07/why-we-shift-objectives-and-not-release-dates-at-gitlab/
>
>
> Greets,
>
> Myrle
>
>
>
>
> *Myrle Krantz*
> Solutions Architect
> RɅĐɅЯ, The Mifos Initiative
> mkrantz@mifos.org | Skype: mkrantz.mifos.org | http://mifos.org
> <http://facebook.com/mifos> <http://www.twitter.com/mifos>
>
>
> On Thu, Jan 7, 2016 at 7:13 PM, Markus Geiss <ma...@live.de> wrote:
>
>> On 01/07/2016 05:36 PM, Roman Shaposhnik wrote:
>>
>>> On Thu, Jan 7, 2016 at 3:52 AM, Myrle Krantz <mk...@mifos.org> wrote:
>>>
>>>> Hi Fin Fans,
>>>>
>>>> To start the conversation on release cycle, I've documented my suggestion
>>>> here:
>>>> https://cwiki.apache.org/confluence/display/FINERACT/Release+Management
>>>>
>>>> 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::.
>>
>
Re: Release cycle 2 months, soak period 2 weeks?
Posted by Myrle Krantz <mk...@mifos.org>.
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://cwiki.apache.org/confluence/display/FINERACT/Release+Management
"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://about.gitlab.com/2015/12/07/why-we-shift-objectives-and-not-release-dates-at-gitlab/
Greets,
Myrle
*Myrle Krantz*
Solutions Architect
RɅĐɅЯ, The Mifos Initiative
mkrantz@mifos.org | Skype: mkrantz.mifos.org | http://mifos.org
<http://facebook.com/mifos> <http://www.twitter.com/mifos>
On Thu, Jan 7, 2016 at 7:13 PM, Markus Geiss <ma...@live.de> wrote:
> On 01/07/2016 05:36 PM, Roman Shaposhnik wrote:
>
>> On Thu, Jan 7, 2016 at 3:52 AM, Myrle Krantz <mk...@mifos.org> wrote:
>>
>>> Hi Fin Fans,
>>>
>>> To start the conversation on release cycle, I've documented my suggestion
>>> here:
>>> https://cwiki.apache.org/confluence/display/FINERACT/Release+Management
>>>
>>> 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::.
>
Re: Release cycle 2 months, soak period 2 weeks?
Posted by Markus Geiss <ma...@live.de>.
On 01/07/2016 05:36 PM, Roman Shaposhnik wrote:
> On Thu, Jan 7, 2016 at 3:52 AM, Myrle Krantz <mk...@mifos.org> wrote:
>> Hi Fin Fans,
>>
>> To start the conversation on release cycle, I've documented my suggestion
>> here:
>> https://cwiki.apache.org/confluence/display/FINERACT/Release+Management
>>
>> 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::.
Re: Release cycle 2 months, soak period 2 weeks?
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Thu, Jan 7, 2016 at 3:52 AM, Myrle Krantz <mk...@mifos.org> wrote:
> Hi Fin Fans,
>
> To start the conversation on release cycle, I've documented my suggestion
> here:
> https://cwiki.apache.org/confluence/display/FINERACT/Release+Management
>
> 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.