Re: [rdf4j-dev] Tweaking git workflow

[Peter Ansell <ansell.peter@xxxxxxxxx>]

I reviewed it with similar comments:

https://github.com/eclipse/rdf4j-doc/pull/30#pullrequestreview-36416372

I would prefer the principle of least surprise for someone familiar
with the Maven versioning norms, particularly around the version
number on the master branch and only having a single tagged commit
where the -SNAPSHOT is temporarily removed, rather than an entire
sequence of commits without -SNAPSHOT.

It may need more emphasis that (to avoid maintainers cherry-picking),
pull request authors need to make the decision on whether it is a
patch or feature much earlier on in the process, when they create
their branch. For contributors who have been using the previous
workflow where everything happened on master, this may be surprising
that they need to make the decision upfront.


On 5 May 2017 at 09:29, Jeen Broekstra <jeen.broekstra@xxxxxxxxx> 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
>
> _______________________________________________
> rdf4j-dev mailing list
> rdf4j-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/rdf4j-dev
>