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 <aging...@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 <dsm...@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 <amurm...@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! > > > > > >
