With the release of Geode 1.12.0 (awesome!), we have a new branch naming
convention starting today:
release/1.12.0 is now support/1.12
As per this RFC, support/1.12 and an accompanying pipeline[1] will be
maintained until Dec 31 2020.
Critical fixes may be proposed at any time. The fix should
Based on the consensus in this thread, we will move forward with this
proposal. We can work out the exact mechanics after we release
v1.12.0 and move that into a support mode.
Thanks for all the feedback.
Anthony
On Fri, Feb 21, 2020 at 5:30 PM Anthony Baker wrote:
>
> Hi everyone,
>
> I'd li
>
> My interpretation is that we would cut support/1.13 from develop on the
> next scheduled cut date (May 4), and make 1.13.0 and all following 1.13.x
> patch releases directly from this branch. Otherwise it becomes a two-step
> process if all patches have to be cherry-picked from develop -> supp
+1 to the proposal and the plan outlined above for the transition period.
On Mon, Mar 2, 2020 at 4:33 PM Owen Nichols wrote:
> My interpretation is that we would cut support/1.13 from develop on the
> next scheduled cut date (May 4), and make 1.13.0 and all following 1.13.x
> patch releases dir
My interpretation is that we would cut support/1.13 from develop on the next
scheduled cut date (May 4), and make 1.13.0 and all following 1.13.x patch
releases directly from this branch. Otherwise it becomes a two-step process if
all patches have to be cherry-picked from develop -> support/x.y
+1 to the proposal as written.
The proposal does talk about support branches, but doesn't describe when
they are created. Is the idea that we create a support/1.X branch as soon
as we release geode 1.X, and then create release branches off of that as
needed?
-Dan
By sticking to the "on-demand" patch release process, then there is no
difference to the current release process, and this proposal adds nothing
of value.
On Tue, Mar 3, 2020 at 12:44 AM Aaron Lindsey
wrote:
> +1 to the proposal as it’s written.
>
> I’m not sure about setting regular intervals f
+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 an
> On Feb 25, 2020, at 1:42 PM, Udo Kohlmeyer 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 lifesp
NOTE: Sorry Udo, you caught me mid-flight in my response to Alexander...
Alexander-
Certainly there are circumstances (e.g. Security vulnerabilites) which may
warrant a patch/maintenance release sooner than 6 weeks, along with other
circumstances may cause a release to take longer than 6 weeks, i
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 p
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.
Likewis
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 shou
>
> 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 cleani
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 op
The proposal mentions "semi-permanent community release managers".
Assuming that a patch release is simpler than a full release, these patch
releases might serve well as training opportunities for first-time release
managers.
+1 if that's the case.
On Tue, Feb 25, 2020 at 9:29 AM Anthony Baker wr
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
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 t
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 vot
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
prop
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
21 matches
Mail list logo
