The expectation is that master always points to the latest release (in this case 1.10.0). There’s a rel/v1.9.2 tag already—what more is needed? We don’t need the release branch since further patches can be branched from that tag. IOW, I don’t understand why we should to overwrite master with an older release.
Anthony > On Nov 12, 2019, at 6:48 PM, Robert Houghton <rhough...@pivotal.io> wrote: > > I think we should look at other examples of git-flow merge practices for > this kind of thing. We can't be the only project that does this. > > But I vote for a merge commit > > On Tue, Nov 12, 2019, 16:20 Owen Nichols <onich...@pivotal.io> wrote: > >> It’s been a few weeks since 1.9.2 release was announced, and there is >> still no record of it on master. What should we do? >> >> A) never record 1.9.2 on master; instead keep the most recent >> release/1.9.x branch around indefinitely (normally we delete release >> branches after pushing them to master). >> B) push 1.9.2 to head of master (on top of 1.10.0). This gives master all >> of the correct tags, even if they are in release-date order rather than >> semantic-version order. >> C) rewrite history (use force-push to insert 1.9.2 onto master in between >> 1.9.1 and 1.10.0) >> D) other? >> >> If it is generally desirable that checking out the head of master should >> always give the latest release (by semantic-version order), we could still >> consider option B, but wait to do it until just before we ship 1.11.0... >> >> -Owen >> >>> On Oct 28, 2019, at 6:51 AM, Jens Deppe <jde...@pivotal.io> wrote: >>> >>> The Apache Geode community is pleased to announce the availability of >>> Apache Geode 1.9.2. >>> >>> Apache Geode is a data management platform that provides a database-like >>> consistency model, reliable transaction processing and a shared-nothing >>> architecture to maintain very low latency performance with high >> concurrency >>> processing. >>> >>> Geode 1.9.2 contains a number of improvements and bug fixes. >>> >>> >>> - Added the ability to specify that when an asynchronous event queue >>> (AEQ) first starts, event processing should be paused. A `resume` >> command >>> is provided to start event processing at the desired time. Three gfsh >>> commands were added or modified to support this capability: "create >>> async-event-queue --pause-event-processing", "alter async-event-queue >>> --pause-event-processing", and "resume async-event-queue-dispatcher". >> See >>> the gfsh command reference in the Geode User Guide for details. >>> - Publish war artifacts for geode-web , geode-web-api and >>> geode-web-management to Maven Central. >>> - Fix compatibility with launching geode-web (admin REST API) when >>> Spring 5.x jars are on the classpath. >>> >>> >>> For the full list of changes please review the release notes: >>> >> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.2 >>> >>> The release artifacts can be downloaded from the project website: >>> http://geode.apache.org/releases/ >>> >>> The release documentation is available at: >>> http://geode.apache.org/docs/guide/19/about_geode.html >>> >>> We would like to thank all the contributors that made the release >> possible. >>> >>> Regards, >>> Jens Deppe on behalf of the Apache Geode team >> >>
