| [rdf4j-dev] Tweaking git workflow |
| 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 |