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