Re: [rdf4j-dev] Tweaking git workflow

[James Leigh <james.leigh@xxxxxxxxxxxx>]

Jeen, see my question below.

On Fri, 2017-05-05 at 09:29 +1000, Jeen Broekstra wrote:
> Following up on our discussion about cherry-picking and James’
> proposal for a slightly different workflow (documented
> here: https://github.com/jamesrdf/rdf4j-doc/blob/issues/%
> 2329-develop/doc/developer/index.adoc ).
> 
> 
> As I understand, the gist of that proposal is to have two active
> branches at all time:
> 
> 
> 1. The master branch tracks patch development on the last stable
> release, and will only contain bug fixes
> 2. The develop branch tracks feature development for the next minor
> release
> 
> 
> The upside is that it won’t be necessary to do cherrypicking anymore,
> making doing patch releases easier. As James remarked, Github has
> improved its UX quite a bit, so it’s a lot easier to change the target
> branch of a PR.
> 
> 
> A potential downside is still that with two active branches, you need
> to keep careful track of what gets merged where, and at what times:
> 
> 
> 1. Master can be regularly merged into devel without problems. When
> should this happen, and who actually does it?
> 2. Devel can only be merged into master immediately after a minor
> release. This means that any development that uses devel as its
> starting branch must merge back into devel (even if the feature turns
> out just to be a bug fix). Potentially it can be cherry-picked back
> into master, but never merged.
> 
> 
> There’s also a minor tweak I'd do to James’ proposal: when the time
> comes to create a release branch for a patch version, (branching off
> from master), don’t immediately set it to (e.g.) 2.2.1, but use
> 2.2.1-SNAPSHOT instead. You may want to do some last-minute
> adjustments on the release branch, warranting several more commits
> (and associated builds). If consecutive builds have the same version
> number, maven can get confused. It’s good practice to only set the
> version number to the fixed number on the commit that will actually
> get tagged and released. 
>  
> All in all I’m ok with the workflow, with the above caveats. 
> 

Jeen, Can you give some examples of what last-minute adjustments might
need to be made on the release branch that wouldn't go into the master
branch?

Thanks,
James