+1 to Dan On Fri, Oct 5, 2018, 09:27 Dan Smith <dsm...@pivotal.io> wrote:
> 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! > > > >>>>>>> > > > >>>>>> > > > >>>>> > > > >>>> > > > >>> > > > >> > > > > > > > > >
