geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Owen Nichols <onich...@pivotal.io>
Subject Re: [DISCUSS] how to record 1.9.2 release on master
Date Wed, 13 Nov 2019 17:37:24 GMT
Great, that sounds like a reasonable expectation & also the simplest solution!

I cleaned up a few release branches that should have already been deleted.  No further action
is needed.

-Owen

> On Nov 13, 2019, at 8:07 AM, Anthony Baker <abaker@pivotal.io> wrote:
> 
> 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 <rhoughton@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 <onichols@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 <jdeppe@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
>>> 
>>> 
> 


Mime
View raw message