fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Geiß <markus.ge...@live.de>
Subject RE: Release cycle 2 months, soak period 2 weeks?
Date Sat, 09 Jan 2016 12:12:12 GMT
+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<mailto:gstein@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<mailto:mkrantz@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 <markus.geiss@live.de> wrote:
> >
> > > On 01/07/2016 05:36 PM, Roman Shaposhnik wrote:
> > >
> > >> On Thu, Jan 7, 2016 at 3:52 AM, Myrle Krantz <mkrantz@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::.
> > >
> >
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message