Real quick thought... IMO: 1. There should be patch (maintenance) releases for each major.minor, up to N-2 for a set period of time (e.g. 1.5 years), or until N-2 becomes N-3 where N-3 is no longer supported. 2. All important changes should be backported. I say "important" loosely since that should be decided by the community, but in general, that means Blocker, Critical, Security fixes or other changes that can impact the contract, functionality or proper behavior of Apache Geode in whatever context. 3. Patch (maintenance) releases should occur at a regular, "predictable" intervals (e.g. every 6 weeks), not on an adhoc basis.
$0.02 -John On Tue, Feb 25, 2020 at 11:23 AM Alexander Murmann <amurm...@apache.org> wrote: > > > > 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. > > > +1 I cannot see any argument against cutting a release branch for the minor > version and keeping it around. > > The community process around deciding how long to gather fixes before > > shipping a patch release isn’t any easier either way. > > How about we wait for someone to call out the need to ship a patch > release. At > that point we use the rule of thumb "aim for no more than 1 patch release > per minor per month" to guide our community discussion. > > 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... > > Are there more things that could be automated? When I filled the role ~1 > year ago there was lots of copying and pasting of scripts and I even wrote > one to help validate fixVersions. Although release process automation > should probably be taken to a different discussion, since it's mostly > separate form Anthony's proposal. > > > On Tue, Feb 25, 2020 at 11:06 AM Owen Nichols <onich...@pivotal.io> wrote: > > > 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 > > >>>> > > >>>> > > >> > > > > -- -John Spring Data Team
