anchor.diff:  When IP log approval and review approval have been given, the review can be scheduled. To do this, emo@eclipse.org needs to be notified. This can happen through the https://projects.eclipse.org/projects/technology.rdf4j/governance[eclipse project governance page] (accessible through the project site), which will show a link at the top of the page for the planned release.
   
   For more detailed information about the release review process, see the https://www.eclipse.org/projects/handbook/[Eclipse Project Handbook].
  +
  +=== Branching minor releases
  +
  +Minor releases are created by branching the _develop_ 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 only features and fixes that have already been scheduled
  +for release be merged into the _develop_ branch, so that there is no confusion
  +as to what will be included in the next minor release.
  +
  +The steps to create a minor release are very similar to the patch release
  +steps, but are based on the _develop_ branch (not the _master_ branch).
  +
  +Once a minor release is published the _develop_ branch should be merged into the
  +_master_ branch (along with the _develop_ branch's version). This will increment the
  +_master_ version to the latest major/minor SNAPSHOT version.
  +Then the _develop_ minor version should be incremented to the next SNAPSHOT
  +version and any approved features that are scheduled for this next minor
  +version should be merged into _develop_ branch.
   
   == Further reading
   
  
positive.code: 
  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.
  
  == 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.
  
  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.
  
  == 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:
  
  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:
  +
      git checkout 2.1.5
  
  
negative.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.2.1'. 
  
  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. 
  
  