geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Barnes <dbar...@pivotal.io>
Subject Re: [DISCUSS] Predictable minor release cadence
Date Fri, 05 Oct 2018 17:18:53 GMT
If we go with more frequent releases, the number of available releases will
ramp up quickly.
What would be the best policy regarding earlier releases?
The Geode website's Release page currently links to 1.7.0, 1.6.0, 1.5.0,
and 1.4.0.
Would it be prudent to adopt a policy (as suggested by Craig Russell,
secretary of ASF) of keeping the available-via-mirror list short by
archiving older releases?
Does this present any hardship to users of older versions? Does it
introduce additional time into the release process that must be accounted
for?
-Dave

On Fri, Oct 5, 2018 at 9:27 AM 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