These concerns make sense. We could satisfy them within our existing “on-demand” process:
1) the first time there is a change to backport to support branches, propose the patch release. Now we have a branch. Decide as a community how urgently it needs to be released vs how long to hold it open for other potential fixes. Or, we could emphasize the shift in process with bigger changes: i. Instead of cutting "release/1.13.0" on May 4, we could instead cut "support/1.13" ii instead of creating "apache-release-1-13-0-main" pipeline, we would instead create "apache-release-1-13-main" iii. Instead of cleaning up the pipeline and branch after 1.13.0 was released, we could keep it around for 9 months and re-use it for collecting patches and making patch releases during that time. The community process around deciding how long to gather fixes before shipping a patch release isn’t any easier either way. One advantage of our current process is that a release doesn’t happen until someone volunteers to make it happen. We can do as many or as few patch releases as the community is willing -- a release always has a champion. I would like to see more discussion on the community impact of increasing the commitment required of a release manager. In the short term it would be good for Geode to have someone focused on improving the release process for a longer period of time than a single release. But in the long term, people may be less likely to volunteer, and release experience will be concentrated in fewer members of the community... > On Feb 25, 2020, at 9:29 AM, Anthony Baker <aba...@pivotal.io> wrote: > > Here’s a couple things I’d like to avoid: > > 1) Issuing a patch release for every single commit that we back port onto a > supported minor version. This seems like a high cost approach. Of course, > some issues may be important enough to require that. > > 2) Merging a change to develop, and then having to come back weeks later and > back porting the change to a release branch. It just seems less optimal > since I’ll have lost the context on the changes, particularly if the > cherry-pick is non-trivial. > > More comments below. > > Anthony > > >> On Feb 24, 2020, at 2:16 PM, Owen Nichols <onich...@pivotal.io> wrote: >> >> Hi Alexander, currently we don’t start a patch release until someone >> proposes a critical fix, which then drives the release (the community may >> propose “extra” fixes to tag along once a release branch is cut). This >> keeps the process simple, neat and tidy. >> >> Another option I hadn’t thought of is to begin collecting “extra” fixes >> proactively on a “dormant” branch, so that when someone finally proposes >> releasing a patch, it will already be primed with a bunch of fixes. This >> adds complexity (does a different standard apply to bring fixes to a dormant >> branch? Are release branches separate from support branches? How will >> committers be able to keep track of what is dormant and what is not?) >> > > Why not just either a) keep the release branch alive? Or b) create a support > branch from the release tag? > >> To implement an N-2 support policy, does it make more sense for Geode to >> make small focused patch releases when needed, or to maintain what amounts >> to “3 develop branches at all times”? >> > > To me, “develop branch” implies ongoing work. I’m proposing “support branch” > which means only important changes agreed upon by the project community. > > >> >>> On Feb 24, 2020, at 11:00 AM, Alexander Murmann <amurm...@pivotal.io> wrote: >>> >>> Thanks for proposing this, Anthony! >>> >>> >>>> I don’t think it’s necessary for this proposal to re-define or clarify >>>> what constitutes a critical fix; it sounds like the bar would be the same >>>> as the standard we already apply when back-porting to release branches >>>> (proposal /w justification, and 3 votes in favor). The only difference >>>> seems to be that now proposals may list up to three target branches, not >>>> just one. >>>> >>> re: Owen >>> TL;DR: +1 using the same process as we use for merging critical fixes >>> during an ongoing release seems appropriate. >>> >>> Generally merging a fix to a dormant release branch seems less problematic >>> than merging a fix to an active release branch where a merge will reset all >>> release work that has already happened. The cost of merging to a >>> dormant release branch is much lower than merging to one that's being >>> actively released. Ideally we could just do a PR to merge fixes back in >>> most cases. Unfortunately, I believe it's unreasonable to expect that >>> everyone will be aware at all times what's actively being released and >>> what's not => Let's pretend we are always shipping these branches. >>> >>> >>> >>> >>> On Fri, Feb 21, 2020 at 7:35 PM Owen Nichols <onich...@pivotal.io> wrote: >>> >>>> Thank you Anthony for proposing this “N-2” support policy. It isn’t a big >>>> change, but it is helpful to know that the Geode PMC will now be standing >>>> behind (and ready to vote on) patch releases within a 9-month window. >>>> >>>> Overall, this sounds much like how 1.9.1 and 1.9.2 started as community >>>> proposals, found a release manager, and went on to be successfully >>>> released. >>>> >>>> I don’t think it’s necessary for this proposal to re-define or clarify >>>> what constitutes a critical fix; it sounds like the bar would be the same >>>> as the standard we already apply when back-porting to release branches >>>> (proposal /w justification, and 3 votes in favor). The only difference >>>> seems to be that now proposals may list up to three target branches, not >>>> just one. >>>> >>>> I also don’t think it’s necessary to alter our current process to maintain >>>> a standing "support/x.y" branch. The proposal states that patch releases >>>> will be “ad-hoc (as needed)”. Our current process serves this quite well: >>>> we propose a patch release at the time it is needed, then get a release >>>> manager and create a release branch specifically for that release (e.g. >>>> release/1.9.2 was created from the rel/v1.9.1 tag), then clean up >>>> afterwards so no unattended pipelines or branches linger. >>>> >>>> The rotating release manager role has been a hallmark of the Geode >>>> community process, so I hope this proposal will not dissuade anyone >>>> interested in helping with a release. However, getting the automation >>>> improvements we need will require some continuity over several releases. I >>>> would love to volunteer for this! >>>> >>>> -Owen >>>> >>>>> On Feb 21, 2020, at 5:30 PM, Anthony Baker <aba...@apache.org> wrote: >>>>> >>>>> Hi everyone, >>>>> >>>>> I'd like to propose shipping patch releases of Geode as a way to >>>>> improve our engagement and support of our user community. Please >>>>> review the details in the linked RFC [1] and kindly offer your >>>>> thoughts in this thread. >>>>> >>>>> >>>>> Thanks, >>>>> Anthony >>>>> >>>>> [1] >>>> https://cwiki.apache.org/confluence/display/GEODE/Shipping+patch+releases >>>> >>>> >> >
