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.