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 <mcmellaw...@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 <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! > > > > > > > > > > > > > > >
