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