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 |
