Re: [rdf4j-dev] Tweaking git workflow

[James Leigh <james.leigh@xxxxxxxxxxxx>]

On Wed, 2017-05-10 at 09:16 +1000, Jeen Broekstra wrote:
> > On 9 May 2017, at 23:16, James Leigh <james.leigh@xxxxxxxxxxxx> wrote:
> > 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.
> >>>> 

I'd like to move forward with this next week. If there are any more
comments please add them to the PR here:
https://github.com/eclipse/rdf4j-doc/pull/30

In particular, I would like feed back on what version the master branch
should follow. I propose not including a patch number, but having a
fixed high patch number would also work just as well. Furthermore, a
high patch number would cause maven to treat the master branch as newer
than patch releases, which might be more consistent.

Regards,
James