Return-Path: X-Original-To: apmail-fineract-dev-archive@minotaur.apache.org Delivered-To: apmail-fineract-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id CB4A91839B for ; Fri, 8 Jan 2016 15:38:40 +0000 (UTC) Received: (qmail 16653 invoked by uid 500); 8 Jan 2016 15:38:38 -0000 Delivered-To: apmail-fineract-dev-archive@fineract.apache.org Received: (qmail 16543 invoked by uid 500); 8 Jan 2016 15:38:38 -0000 Mailing-List: contact dev-help@fineract.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@fineract.incubator.apache.org Delivered-To: mailing list dev@fineract.incubator.apache.org Received: (qmail 16521 invoked by uid 99); 8 Jan 2016 15:38:38 -0000 Received: from Unknown (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Jan 2016 15:38:38 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 962EAC0D2C for ; Fri, 8 Jan 2016 15:38:37 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 4.214 X-Spam-Level: **** X-Spam-Status: No, score=4.214 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=3, URIBL_BLOCKED=0.001, URI_HEX=1.313] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id ylqYJPvyMCmB for ; Fri, 8 Jan 2016 15:38:25 +0000 (UTC) Received: from mail-vk0-f49.google.com (mail-vk0-f49.google.com [209.85.213.49]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 3307020511 for ; Fri, 8 Jan 2016 15:38:25 +0000 (UTC) Received: by mail-vk0-f49.google.com with SMTP id k1so193425763vkb.2 for ; Fri, 08 Jan 2016 07:38:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=LU8ktmeUVp+t3TzyLj/3RX0q1I2+IuSxbFMk7dFoISc=; b=iCjmGTyzSQdH6Q+dF95uJfopEE4oNEj3jy08ZVkodxRD/jgNqeW1AH7p56shaNqgzg hlhKgQtJAS3DnmVnUbY0Co1hy/Y63Ze/BAahfQZB2lxMrW91WhI894Qici/myOiT17z6 D6DFk1EWk7O9O87s+69mbRkdkdQjx32c0KgjSXY84gL7CRJg1quqy4iwZ8CVJ+IJTE1M rKUdZIYLvvpfhjlH9sk+MzlRoYuxJIBgxrTZEw7I6zJ8DS/I7yE63rG0OLM+SqZqTNWg uRVP+h4hz3g6bkWNYrK4ZWNb1OTYQ6pjGRcQKr3rkuxCRat6aAHJYjUFDnLtRrEBu4Qa epRQ== MIME-Version: 1.0 X-Received: by 10.31.183.74 with SMTP id h71mr78369451vkf.141.1452267503908; Fri, 08 Jan 2016 07:38:23 -0800 (PST) Received: by 10.31.220.70 with HTTP; Fri, 8 Jan 2016 07:38:23 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Jan 2016 09:38:23 -0600 Message-ID: Subject: Re: Release cycle 2 months, soak period 2 weeks? From: Greg Stein To: dev@fineract.incubator.apache.org Content-Type: multipart/alternative; boundary=001a11439d02b07ca00528d460bd --001a11439d02b07ca00528d460bd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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 document= ed > in policy. That is cut a release whenever one is needed rather than when > someone else in the community decides its time. Remember anyone (committe= r > or otherwise) can produce a release candidate and releases cannot be veto= ed > (thigh releases need to be approved by the PPMc). > > I'm not trying to put a stop to policy working, but honestly, starting th= e > removal of non-compliant licenses will get us to that first release much > more quickly. > > Ross > > > Sent from my Windows Phone > ________________________________ > From: Myrle Krantz > Sent: =E2=80=8E1/=E2=80=8E8/=E2=80=8E2016 9:57 AM > To: dev@fineract.incubator.apache.org 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=3Dhttps%3a%2f%2fcwiki.= apache.org%2fconfluence%2fdisplay%2fFINERACT%2fRelease%2bManagement&data=3D= 01%7c01%7cRoss.Gardler%40microsoft.com%7cbd07f873744844790f8908d318122a65%7= c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DObRmLmfpC6ceQGQZuXCe0ZcOR6kHo= 1kpInNIMNGom14%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 mak= e > 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 finishe= d > two days after the deadline, I would expect the release to come at the ne= xt > two-monthly release. > > Gitlab does something similar, but with a release period of one month: > > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fabout.= gitlab.com%2f2015%2f12%2f07%2fwhy-we-shift-objectives-and-not-release-dates= -at-gitlab%2f&data=3D01%7c01%7cRoss.Gardler%40microsoft.com%7cbd07f87374484= 4790f8908d318122a65%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DmPfHddys= NWSr5Ny2Mn3WIiNm2l%2blpeZ9%2fBpvZMoKuKs%3d > > > Greets, > > Myrle > > > > > *Myrle Krantz* > Solutions Architect > R=C9=85=C4=90=C9=85=D0=AF, The Mifos Initiative > mkrantz@mifos.org | Skype: > https://na01.safelinks.protection.outlook.com/?url=3Dmkrantz.mifos.org&da= ta=3D01%7c01%7cRoss.Gardler%40microsoft.com%7cbd07f873744844790f8908d318122= a65%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DmWTUs0BSMkHgTc1HEjL74ThI= 91jT79Xnk%2f8WZokmg8U%3d > | > https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f%2fmifos.o= rg&data=3D01%7c01%7cRoss.Gardler%40microsoft.com%7cbd07f873744844790f8908d3= 18122a65%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DjXa1LqIPVvsHvmrGi6v= GEhPMNbisByxEDKxfATf0LQk%3d > < > https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f%2ffaceboo= k.com%2fmifos&data=3D01%7c01%7cRoss.Gardler%40microsoft.com%7cbd07f87374484= 4790f8908d318122a65%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3D2Y1ZdQx3= 5Uymx841zX1J3ckaI2wRihC8APzFYYsPmNc%3d> > < > https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f%2fwww.twi= tter.com%2fmifos&data=3D01%7c01%7cRoss.Gardler%40microsoft.com%7cbd07f87374= 4844790f8908d318122a65%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DJu51b= sgXVuYDROgkNLYE7ytn%2b6Q3M6TamHHm6f43qgg%3d > > > > > 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: > >>> > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fcwiki.= apache.org%2fconfluence%2fdisplay%2fFINERACT%2fRelease%2bManagement&data=3D= 01%7c01%7cRoss.Gardler%40microsoft.com%7cbd07f873744844790f8908d318122a65%7= c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DObRmLmfpC6ceQGQZuXCe0ZcOR6kHo= 1kpInNIMNGom14%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-drive= n > >> 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::. > > > --001a11439d02b07ca00528d460bd--