geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Houghton <rhough...@pivotal.io>
Subject Re: [DISCUSS] Predictable minor release cadence
Date Fri, 05 Oct 2018 01:39:53 GMT
I have found it refreshing that the geode released cadence has been based
on features being done,  rather than a set schedule.

I come from an environment where we had quarterly releases and monthly
patches to all supported previous releases, and I can tell you that it
became a grind. That being said, within that release cadence a one-month
ramp for bug fixes on the release branch was almost always sufficient.

On Thu, Oct 4, 2018, 18:32 Ryan McMahon <mcmellawatt@apache.org> wrote:

> +1 for scheduled releases and cutting the branch one month prior to
> release. Given the time it took to fully root out, classify, and solve
> issues with this 1.7 release, I think a month is the right amount of time
> between cutting the branch and releasing.  If it ends up being too much or
> too little, we can always adjust.
>
> I don’t feel strongly about the release cadence, but I generally favor more
> frequent releases if possible (3 month over 6 month).  That way new
> features can get into the hands of users sooner, assuming the feature takes
> less than 3 months to complete.  Again, we can adjust the cadence if
> necessary if it is too frequent or infrequent.
>
> Ryan
>
> On Thu, Oct 4, 2018 at 4:18 PM Alexander Murmann <amurmann@pivotal.io>
> wrote:
>
> > Anil, releasing every 3 months should give us 3 months of dev work. Don't
> > forget that there will be one month during which the next release is
> > already cut, but the vast majority of the work is going to the release
> > after that. So while we cut 1.7 one month ago and release 1.7 today, we
> > already have one month of work on develop again. It's not going to work
> out
> > for this first release though, due to my suggestion to cut a month early
> to
> > avoid holidays. If I recall correctly our past problem was that it took
> > longer to iron out issue on the release branch than expected. The
> solution
> > to that would be to cut the release even earlier, but 1 month feels very
> > generous.
> >
> > On Thu, Oct 4, 2018 at 4:04 PM Anilkumar Gingade <agingade@pivotal.io>
> > wrote:
> >
> > > If I remember from earlier discussion; the plan was to deliver a
> release
> > > once 3 months. But from the past release history we had difficulty in
> > > achieving that, either the features are not completely ready or the
> > > bug-fixes have taken more time. We need verify what is right for Apache
> > > Geode, 3, 4 or 6 months; and there is any community dev/activity that
> > > depends on Geode release.
> > > My vote will be for 4 or 6 months, as it provides at least 3+ month for
> > dev
> > > activity and 1 month for QA.
> > >
> > > -Anil.
> > >
> > >
> > > On Thu, Oct 4, 2018 at 2:43 PM Dan Smith <dsmith@pivotal.io> wrote:
> > >
> > > > +1 I definitely like the idea of scheduled releases.
> > > >
> > > > I wonder if cutting the release branch a month ahead of time is
> > overkill,
> > > > but I guess we do seem to keep finding issues after the branch is
> cut.
> > > >
> > > > -Dan
> > > >
> > > > On Thu, Oct 4, 2018 at 1:25 PM Alexander Murmann <
> amurmann@pivotal.io>
> > > > wrote:
> > > >
> > > > > Hi everyone,
> > > > >
> > > > > I want to propose shipping Geode on a regular cadence. My concrete
> > > > proposal
> > > > > is to ship Geode every 3 months on the first weekday. To make sure
> we
> > > hit
> > > > > that date we would cut the release 1 months prior to that day.
> > > > >
> > > > > *Why?*
> > > > > Knowing on what day the release will get cut and on what day we
> ship
> > > > allows
> > > > > community members to plan their contributions. If I want my feature
> > to
> > > be
> > > > > in the next release I know by when I need to have it merged to
> > develop
> > > > and
> > > > > can plan accordingly. As a user who is waiting for a particular
> > feature
> > > > or
> > > > > fix that's already on develop, I know when to expect the release
> that
> > > > > includes this work and again, can plan accordingly.
> > > > >
> > > > > This makes working and using Apache Geode more predictable which
> > makes
> > > > all
> > > > > our lives less stressful. To make this work, it's important to be
> > > strict
> > > > > about cutting the release branch on the set date and only allow
> > > critical
> > > > > fixes after the release has been cut. Once we start compromising
on
> > > this,
> > > > > we go down a slippery slope that ultimately leads to not getting
> the
> > > > > predictability benefits described here.
> > > > >
> > > > > Some other successful Apache projects share similar approaches:
> > > > >
> > > > >    - Kafka
> > > > >    <
> > > >
> https://cwiki.apache.org/confluence/display/KAFKA/Future+release+plan>
> > > > >    releases every 4 months and cuts the release 1 month prior
> > > > >    - PredictionIO <
> > https://predictionio.apache.org/resources/release/>
> > > > > releases
> > > > >    every 2 months
> > > > >    - Spark <https://spark.apache.org/versioning-policy.html>
does
> > not
> > > > seem
> > > > >    to have a hard date, but aims to ship every 6 months, so there
> is
> > at
> > > > > least
> > > > >    a goal date
> > > > >
> > > > >
> > > > > *What?*
> > > > > As stated above, I suggest to release every three months. Given we
> > just
> > > > > shipped the next release would go out on January 2nd. That timing
> in
> > > > > unfortunate, due to the holidays. Therefore I propose to aim for
a
> > > > December
> > > > > 3rd (1st Monday in December) release. In order to meet that date,
> we
> > > > should
> > > > > cut the release branch on November 1st. That also means that we
> > should
> > > > > start finding a volunteer to manager the release on October 25th.
I
> > > know
> > > > > this seems really close, given we just shipped, but keep in mind
> that
> > > > this
> > > > > is to avoid the holidays and that we already have close to a month
> > > worth
> > > > of
> > > > > work on develop.
> > > > >
> > > > > *Proposed near future schedule:*
> > > > > October 25th: Find release manager
> > > > > November 1st: Cut 1.8 release branch
> > > > > December 1st: Ship 1.8
> > > > > January 28th: Find release manager
> > > > > February 1st: Cut 1.9 release branch
> > > > > March 1st: Ship 1.9
> > > > > and so on...
> > > > >
> > > > > Thanks for sharing your thoughts and feedback on this!
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message