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?) 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”? > 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 >> >>
