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 mightneed to be made on the release branch that wouldn't go into the masterbranch?
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.
Cheers,
Jeen |