+1 to the proposal as it’s written.
I’m not sure about setting regular intervals for patch releases vs sticking
with our current “on-demand” process. I don’t think this has to be spelled out
in this proposal. I’d be fine with sticking to “on-demand” patch releases as
we’ve been doing for now and seeing how that goes. If needed we could follow
that up with a proposal for regular patch release intervals.
- Aaron
> On Feb 26, 2020, at 8:45 AM, Anthony Baker <aba...@pivotal.io> wrote:
>
>
>
>> On Feb 25, 2020, at 1:42 PM, Udo Kohlmeyer <u...@apache.com> wrote:
>>
>> From the proposal it seems we are departing from the initial delivery
>> paradigm of "always upgrade to the latest version, because all fixes are
>> going in there", to the more product orientated approach of, there is a
>> support lifespan for each {major}-{minor} version. Which is a more
>> traditional product approach.
>>
>> Is there a specific reason we advocating for moving away from "the fix will
>> be in the latest release X:Y:Z" ?
>>
>
> From the proposal:
>
> "The Geode project has been following a model of shipping releases quarterly
> [1][2]. Using the SemVer [3] approach, these quarterly releases are labeled
> as minor versions. Occasionally, the project has shipped patch releases [4]
> to address security vulnerabilities or really critical bugs. However, on the
> whole the project has asked users to wait until the next quarterly minor
> release to receive improvements and fixes.
>
> It would benefit our user community if we supported our releases for a period
> of time by back porting important fixes and providing patch releases.”
>
> I believe that taking this approach will clarify expectations and make it
> easier for users to rely on Geode for their projects.
>
>
>> The current methodology or the community voting on changes being
>> cherry-picked is related to fixes making it into an unreleased version of
>> Geode. From the proposal, are we advocating for extra voting "Do we include
>> fix GEODE-XXXX, into N , N-1 or N-2? " This does seem to be something that
>> might be more work for the community, rather than just updating to latest
>> RELEASE. Or is the suggestion that closer to each release period, a list of
>> candidate tickets are proposed for back porting? Or is the back porting and
>> vote on inclusion done based on discretion and on a ticket by ticket basis?
>
> I think the process will follow our approach to back porting fixes onto a
> release branch:
>
> 1) When you fix an “important” issue, note that it will need to be back
> ported onto the correct set of support branches.
> 2) The assigned release manager for the support branch will coordinate
> community consensus and help with cherry-picking the change as well as
> ensuring the pipelines are staying green.
>
>>
>> With the reduced scope of supported versions, does this also mean we reduce
>> scope of backward compatibility testing between versions? i.e can we now
>> change our backward compatibility testing to mimic the same behavior where
>> we only test compatibility between, HEAD,N,N-1 and N-2?
>>
>
> Great question. I think we continue to follow our SerVer approach to naming
> versions, as well as following the backwards compatibility guidelines
> described in [1[. In short, I don’t think this N-2 changes our
> requirements—this idea is more about what versions we will patch.
>
>
> Anthony
>
> [1]
> https://cwiki.apache.org/confluence/display/GEODE/Managing+Backward+Compatibility
>
>
>
>
>> --Udo
>>
>> On 2/25/20 11:51 AM, Alexander Murmann wrote:
>>> Hi John,
>>>
>>> I think what you are calling out in 1. and 2. matches what was discussed in
>>> the proposal and thread. Please call out if you disagree on a detail.
>>>
>>> What's your reasoning behind 3?
>>> I see little reason to ship a patch release (which is significant work) if
>>> there was no important fix.
>>> Likewise I am concerned about waiting to ship a critical fix to our users
>>> or leave them with gaping security vulnerabilities when we have a fix, but
>>> the next patch release train doesn't depart for several weeks.
>>>
>>> On Tue, Feb 25, 2020 at 11:41 AM John Blum <jb...@pivotal.io> wrote:
>>>
>>>> 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
>>>>
>>>
>
