[rdf4j-dev] Releases, branching, etc - a summary of the current approach

[Jeen Broekstra <jeen.broekstra@xxxxxxxxx>]

This is something that was discussed in https://github.com/eclipse/rdf4j/issues/266, and has now been implemented and also documented in the Contributor Guidelines, however I just realised I never sent a full summary/overview to this list, so here goes:

Workflow

The short-short version for contributors: work from the master branch.

The more complete version: RDF4J uses a git branching model where feature development takes place on branches from the master branch. This is where all development for the next (minor or major) release happens.

Every issue, no matter how small, gets its own branch while under development. Issue branch names are always prefixed with issues/, followed by the issue number in the GitHub issue tracker, followed by one or two dash-separated keywords for the issue.

For example: issues/#276-rdfxml-sax is the branch for a fix for GitHub issue #276, which has to do with RDF/XML and the SAX parser.

Once a feature/fix is complete, tested, and reviewed (via a Pull Request), it is merged into master, and the issue branch is closed.

Releases

RDF4J is on an 8-week release cycle for minor and major releases. See the Milestone overview in the issue tracker for an overview of planned releases.

In order to guarantee stability of the release and to ensure we have enough time to complete release review, we use a feature cutoff date. This date is typically three weeks before the release date. The feature cutoff date does not mean that each feature needs to be complete, but it does mean that we ask every contributor to make a commitment to have their feature complete and stable in time for final review and release. If a contributor cannot make that commitment, the feature is not included in the release and is simply "postponed" to the next release cycle.

We occasionally also schedule patch releases, which only include (backward compatible) bug fixes. These releases are typically planned on short notice and can be done without much in the way of formal review.

Release branches

A few days before release of a minor or major version, we create a release branch from the current head of the master branch. The purpose of this release branch is to perform last-minute tweaks and little fixes. Once we are ready to release, the latest commit of the release branch is tagged with the version number, and the release branch is merged back to master, then closed.

So one consequence of this is that I need you all to let me know if a bug fix you contributed is critical enough that you’d like to do a quick patch release with it. Otherwise it just gets merged into master and released when the next minor/major version is due. 

As for the Java 7 back porting: the current planning, as said, is not to do further major/minor versions (so no parallel 1.1 to the upcoming 2.1 release) - however we will do a parallel 1.0.x if we decide to do a 2.0.x patch release. 

We can decide to continue 1.1 back port releases, but in that case I will need someone to step up and commit to being “the person in charge” of the back port branch. If we go this way, we’ll create a new permanent branch parallel to master, presumably called something like ‘backport-java7’, into which master can be merged at regular intervals, and on which compilation errors can be fixed as necessary.  Please note that we can only do this approach if one of you can make a solid commitment to maintain this: I personally don’t want to spend too much time on this past 2.0.x, and I also do not want to get into the situation where release is held up because the java 7 back port branch is not ready. 

I hope this clears up any remaining confusion.

Cheers,

Jeen