Ok, I buy your arguments to cut the release branch 1 month ahead of time. I'm fine with that plan, as long as we can stick to only putting critical fixes on the release branch. Once the release branch is cut, it ships without further changes unless we find new issues.
-Dan On Fri, Oct 5, 2018 at 8:58 AM Alexander Murmann <amurm...@pivotal.io> wrote: > Robert and Sai, I think either release process can be stressful if your > team doesn't understand that there is no faster button, but that the only > lever is to cut scope (you can also compromise quality, but let's not do > that). > In either scenario there can be release pressure. To me the biggest > difference is that with a fixed schedule I at least have a good chance to > see sooner that I need to cut scope to catch the next train. Without a > fixed schedule, I suddenly might find myself in the situation that everyone > else is ready to ship and is waiting on me and getting impatient. I might > have not even been able to see that coming unless I am constantly checking > with everyone else to find out when they think they might be ready to ship. > > To the Kafka & Spark point: I'd love to see Geode evolve rapidly and have a > massively growing community 😉 > > On Fri, Oct 5, 2018 at 8:45 AM Anthony Baker <aba...@pivotal.io> wrote: > > > I’ve been advocating for a fixed release schedule for a long time. 3 > > months seems like a good rate given the release overhead. > > > > +1 on cutting the next release branch in November and shooting for an > > early December v1.8.0 release. > > > > Anthony > > > > > > > On Oct 4, 2018, at 6:48 PM, Sai Boorlagadda <sai.boorlaga...@gmail.com > > > > wrote: > > > > > > 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! > > >>>>>>> > > >>>>>> > > >>>>> > > >>>> > > >>> > > >> > > > > >
