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 18:54:17 GMT
+1 to Dan

On Fri, Oct 5, 2018, 09:27 Dan Smith <dsmith@pivotal.io> wrote:

> Ok, I buy your arguments to cut the release branch 1 month ahead of time.
> I'm fine with that plan, as long as we can stick to only putting critical
> fixes on the release branch. Once the release branch is cut, it ships
> without further changes unless we find new issues.
>
> -Dan
>
>
> On Fri, Oct 5, 2018 at 8:58 AM Alexander Murmann <amurmann@pivotal.io>
> wrote:
>
> > Robert and Sai, I think either release process can be stressful if your
> > team doesn't understand that there is no faster button, but that the only
> > lever is to cut scope (you can also compromise quality, but let's not do
> > that).
> > In either scenario there can be release pressure. To me the biggest
> > difference is that with a fixed schedule I at least have a good chance to
> > see sooner that I need to cut scope to catch the next train. Without a
> > fixed schedule, I suddenly might find myself in the situation that
> everyone
> > else is ready to ship and is waiting on me and getting impatient. I might
> > have not even been able to see that coming unless I am constantly
> checking
> > with everyone else to find out when they think they might be ready to
> ship.
> >
> > To the Kafka & Spark point: I'd love to see Geode evolve rapidly and
> have a
> > massively growing community 😉
> >
> > On Fri, Oct 5, 2018 at 8:45 AM Anthony Baker <abaker@pivotal.io> wrote:
> >
> > > I’ve been advocating for a fixed release schedule for a long time.  3
> > > months seems like a good rate given the release overhead.
> > >
> > > +1 on cutting the next release branch in November and shooting for an
> > > early December v1.8.0 release.
> > >
> > > Anthony
> > >
> > >
> > > > On Oct 4, 2018, at 6:48 PM, Sai Boorlagadda <
> sai.boorlagadda@gmail.com
> > >
> > > wrote:
> > > >
> > > > I agree with Robert that we should release based on features that go
> > in.
> > > >
> > > > I am not sure if Apache Kafka & Spark are a good reference for GEODE.
> > > > These tools were evolving rapidly in the last couple of years and
> > > frequent
> > > > releases would be good for a growing community.
> > > >
> > > > Should we do a patch release every few months to include bug fixes?
> > > >
> > > > Sai
> > > >
> > > >
> > > > On Thu, Oct 4, 2018 at 6:40 PM Robert Houghton <rhoughton@pivotal.io
> >
> > > wrote:
> > > >
> > > >> 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