Re: [rdf4j-dev] Tweaking git workflow

[James Leigh <james.leigh@xxxxxxxxxxxx>]

Jeen and Peter please see my comments below.

On Sat, 2017-05-06 at 10:57 +1000, Jeen Broekstra wrote:
> 
> > On 5 May 2017, at 23:10, James Leigh <james.leigh@xxxxxxxxxxxx>
> > wrote:
> > 
> > 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.
> > > 
> > 
> > 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?
> > 
> 
> A tweak in a test, a minor last-minute fix (either a bug fix or
> something editorial), etc. That’s the kind of thing I was thinking of.
> Of course, you can also just do this fixes on master before you branch
> off for release, but in practice it can happen that you branch off,
> then remember something you need to fix.
> 
> 
> If we don’t want that to happen, then perhaps we should not branch for
> patch releases at all. After all why create a branch if you’re not
> going to commit anything on it? Simply continue working on master
> until it’s in release-ready state, then set the pom version numbers to
> X.Y.Z and tag the commit with the release tag. Then after release set
> the master version back to X.Y-SNAPSHOT.
> 

Jeen, the instructions I wrote do not include pushing the release branch
to github (intentionally). However, I'd worry that if a local branch is
not created first someone might accidentally push the version commit to
master unexpectedly. Whereas I think that is less likely if changing the
version is done on a local branch.

Peter, I don't think it will be too much of a problem in practise for
maven to think master is older then the latest patch release. If we
release frequently enough they will usually be the same and most ppl
that go to the trouble of building from source will be doing it for the
new features in the develop branch anyway, which does not have this
problem. For those that can't wait for the next patch release though,
they have the option of using an explicit version in their project's
pom.xml (until the fix is released).

Please indicate on github if you approve this workflow change.

Regards,
James