fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject RE: Release cycle 2 months, soak period 2 weeks?
Date Fri, 08 Jan 2016 12:59:42 GMT
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.


Sent from my Windows Phone
From: Myrle Krantz<>
Sent: ‎1/‎8/‎2016 9:57 AM
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:

"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:



*Myrle Krantz*
Solutions Architect
RɅĐɅЯ, The Mifos Initiative | Skype:

On Thu, Jan 7, 2016 at 7:13 PM, Markus Geiss <> wrote:

> On 01/07/2016 05:36 PM, Roman Shaposhnik wrote:
>> On Thu, Jan 7, 2016 at 3:52 AM, Myrle Krantz <> wrote:
>>> Hi Fin Fans,
>>> To start the conversation on release cycle, I've documented my suggestion
>>> here:
>>> 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::.
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message