anchor.diff:  
   For patch releases we never allow changes in the public API, unless the change is specifically to fix a bug that aligns the actual behavior of the code with the publicly documented behavior.
   
  +Only release branches (more on those later) include the full major.minor.patch
  +version numbers included with releases. The major and minor version of the _master_ and
  +_develop_ branches do not include a patch number and always have a SNAPSHOT tag.
  +The _master_ and _develop_ versions always matches the pattern *MAJOR*.*MINOR*-SNAPSHOT.
  +
  +The _master_ version always has the same major and minor number as the latest
  +release while the _develop_ version uses the next expected major/minor
  +release number, such as 2.1-SNAPSHOT 2.2-SNAPSHOT respectively
  +(after a 2.1.x release, but before any 2.2.x releases are made public).
  +
   == Workflow
   
  -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.
  +RDF4J uses a git branching model where feature development takes place on branches from the _develop_ branch. This is where all development for the next (minor or major) release happens.
  +These branches should have the prefix `features/` to indicate they are either
  +not complete or have not been scheduled for the next minor release.
   
   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 https://github.com/eclipse/rdf4j/issues/276[#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.
  +Once a issue is complete and tested, a Pull Request should be created for
  +peer review.
  +
  +=== Pull Request Patch
  +
  +If the change is a bug fix, contains no new features, and
  +does not change any public or protected APIs (class or method signatures in the
  +core module, i.e. code included in the release archive) then the Pull Request should
  +target the _master_ branch. Once the Pull Request is created it should be reviewed
  +and any modifications can be made to the issue branch as recommended.
  +Once a Pull Request has been approved it can be schedule for a patch release by
  +updating the https://github.com/eclipse/rdf4j/projects/3[patch release project board].
  +Only when a Pull Request is approved *and* scheduled for the next patch release it can be merged
  +into the _master_ branch then the issue branch can be closed.
  +
  +=== Feature issues
  +
  +Pull Requests that don't qualify for a patch release should target the _develop_
  +branch or a relevant feature branch.
  +Once a Pull Request has been approved it can be schedule for a major/minor release
  +by updating the https://github.com/eclipse/rdf4j/projects/2[minor release project board]
  +or the https://github.com/eclipse/rdf4j/projects/4[major release project board].
  +Only when a Pull Request is approved *and* scheduled for the next minor release it can be merged
  +into the _develop_ branch, only then can the issue/feature branch can be closed.
  +Minor and major releases require a formal https://www.eclipse.org/projects/handbook/#release-review[release review], and because this is the case, they need to be planned well in advance, and the project lead needs to manage what can go into each release, and prepare necessary documentation (both technical and legal) for review.
  +For this reason approved Pull Requests may stay open for some time until a
  +release plan that incorporates these changes is in place.
   
   == Patch releases
   
  -Patch releases are created by cherry-picking desired bug fixes from the master branch into a release branch, and when complete, tagging this release branch with the version number before release deployment. Once release deployment is complete, the release branch is merged back into the master branch, and then deleted.
  -
  -A patch release can be done in an ad-hoc fashion, without the need for a formal review. Plans to do a patch release are announced by the project lead on the https://dev.eclipse.org/mailman/listinfo/rdf4j-dev[rdf4j-dev@eclipse.org mailinglist], usually about a week in advance, with an open invitation for contributers to propose additional fixes to include.
  -
  -=== Creating a release branch
  -
  -A patch release uses its immediate predecessor release as its basis. This means we need to create a release branch not by simply branching from the current master branch, but by branching from a specific release tag. To create a patch release branch, follow these steps:
  +Patch releases are created by branching the _master_ branch into a release branch, and
  +when complete, tagging this release branch with the version number before
  +release deployment. Once release deployment is complete, the release branch
  +is deleted.
  +
  +It is important that the _master_ branch is always in a release ready state, so
  +a patch release from the _master_ branch can be done in an ad-hoc fashion,
  +without the need for a formal review. Plans to do a patch release are announced
  +by the project lead on the
  +https://dev.eclipse.org/mailman/listinfo/rdf4j-dev[rdf4j-dev@eclipse.org mailinglist],
  +usually about a week in advance, with an open invitation for contributors to
  +propose additional fixes to include, which are done as Pull Requests to the
  +_master_ branch.
  +
  +=== Creating a patch release branch
  +
  +Any fixes to be included in the a patch release must be merged into the _master_
  +branch first.
  +A patch release branch should differ from the _master_ branch, at the time of
  +release, only by the version number - a patch release branch has a patch number
  +version, while the _master_ branch has a SNAPSHOT version.
  +To create a patch release branch, follow these steps:
  +
  +1. Check out the _master_ branch.
  ++
  +E.g. if we're preparing a release 2.2.1, the _master_ branch will have the version 2.2-SNAPSHOT:
  ++
  +    git checkout master
  +
  +2. Create a new release branch, named `releases/<version>`:
  ++
  +    git checkout -b releases/2.2.1
  +
  +3. Fix maven version numbers in the release branch.
  ++
  +We need to set the project version to `2.2.1` by using:
  ++
  +    mvn versions:set
  ++
  +This will ask for the new version number. Enter `2.2.1` to indicate that this is the release branch for 2.2.1 release.
  ++
  +After this is done, execute
  ++
  +    mvn versions:commit
  ++
  +which will remove backup files.
  ++
  +Finally, commit the version number changes:
  ++
  +    git commit -s -a -m "release branch for 2.2.1"
  +
  +4. Tag the version and push the tag upstream:
  ++
  +    git tag 2.2.1
  +    git push -u origin 2.2.1
  +
  +== Hotfix releases
  +
  +Hotfix release are patch releases that target an prior minor version (not the
  +latest stable release). These are needed when a critical bug was found in a
  +production deployment using an earlier version.
  +
  +A Hotfix release use a preceding release as its basis. This means we need to create a release branch not by simply branching from the current _master_ branch, but by branching from a specific release tag. To create a patch release branch, follow these steps:
   
   1. Check out the tag of the previous release.
   +
  -E.g. if we're preparing a release 2.1.6, the previous release is 2.1.5, so we do:
  +E.g. if we're preparing a release 2.1.6, the preceding release is 2.1.5, so we do:
   +
       git checkout 2.1.5
   
  
positive.code: 
  === Building and uploading Maven artifacts
  
  We use the https://hudson.eclipse.org/rdf4j[Eclipse RDF4J Hudson CI instance] to build and deploy new releases to the Central Repository. To do this, simply log in to Hudson, and start the job named `rdf4j-deploy-release-ossrh-central`. The job will ask for the release tag as an input parameter, e.g. '2.1.6'. 
  
  This Hudson job will automatically check out the release tag, build the project, and upload all artifacts to https://oss.sonatype.org/[OSS Sonatype]. After successful upload, it will also automatically invoke synchronization with the Central Repository. Note that after successful completion, the artifacts may not be available on the Central Repository for several hours. 
  
  
negative.code: RDF4J strives to apply http://www.semver.org/[Semantic Versioning] principles to its development:
  
  1. We use a `MAJOR.MINOR.PATCH` versioning template.
  2. A *PATCH* release (2.2.1, 2.2.2, etc.) is a release that contains only bug fixes that are backwards compatible.
  3. A *MINOR* release (2.0, 2.1, 2.2, etc.) is a release that can contain improvements and new features but makes no backward-incompatible changes to existing functionality.
  4. A *MAJOR* release (1.0, 2.0, 3.0, etc) is a release that can contain changes to the public API that are not backward compatible.
  
  