Re: [rdf4j-dev] Tweaking git workflow

[Jeen Broekstra <jeen.broekstra@xxxxxxxxx>]

> On 9 May 2017, at 23:16, James Leigh <james.leigh@xxxxxxxxxxxx> wrote:
> 
> 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.

I see. I tend to think of local repos as an exact mirror of the GitHub repo, so if a branch is created locally that should be reflected on the central repo as well. But if your point is to have a short-lived local branch for “prepping” the release quickly, and then merging that directly into master before pushing to Github, then I guess that’s fine.

> 
> Please indicate on github if you approve this workflow change.
> 



Good point, I’ll move my comments to the PR.


Jeen