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
I think that sounds reasonable. There are two threads involved - the
ReconnectThread, which is running InternalDistributedSystem.reconnect(), and
the Location Services Restart Thread, which is running code in InternalLocator.
If one of them gives up it ought to stop the other one as well and m
Hi geode dev,
please could someone review PRs:
* https://github.com/apache/geode/pull/4711
* https://github.com/apache/geode/pull/4719
Thanks,
Mario
10 matches
Mail list logo
