geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Smith <dsm...@pivotal.io>
Subject Re: [DISCUSS] Predictable minor release cadence
Date Thu, 04 Oct 2018 21:42:56 GMT
+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