anchor.diff:  2. Go to remote directory `/home/data/httpd/download.eclipse.org/rdf4j`. 
   3. Upload the SDK and onejar archives to this directory (NB we currently only distribute the SDK zip file, not the tar.gz file)
   
  -=== Closing the release branch
  -
  -Once the release is complete, the project lead merges the release branch back into the master branch, and then deletes it. 
  -
  -On merge, usually conflicts will occur on all `pom.xml` files - this is due to version number updates in the release branch. These conflicts can be easily resolved by just selecting all pom files and indicating that the conflict should be resolved by just using the master ("mine") version.
  -
  -Once the branch is merged, it needs to be deleted. Although this can of course be done from the command line, it is cumbersome, and we recommend using a decent Git client (like SourceTree) that can do this for you.
  -
  -Note that, although the branch is deleted, the release tag is still in place, for future use of further patch release branches.
  -
   == Minor and Major releases
   
  -The technical steps involved in creating a minor or major release are almost identical to those for creating a patch release. The main difference is that a release branch is usually not created until a few days before the planned release, and it is created directly from the master branch, not from the tag of the previous release. For this reason, it also does not involve cherry-picking fixes.
  -
  -However, 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.
  -
  -=== Release planning
  -
  -We plan each release about 8 weeks in advance. At this stage, the final feature set is not etched in stone but a number of priority features/improvements is identified (via discussion on the mailinglist and/or via issue tracker comments and PRs) and scheduled. A first draft of a release plan is created by the project lead on the https://projects.eclipse.org/projects/technology.rdf4j[Eclipse RDF4J project site], and the necessary milestones are created in the https://github.com/eclipse/rdf4j/issues[RDF4J issue tracker]. In addition, the https://github.com/eclipse/rdf4j/projects/2[next minor release planning board] is updated. 
  -
  -=== Scheduling a release date
  -
  -A release can only be done once its review is succesfully concluded. Eclipse release review are announced in regular cycles, and always complete on the first or third Wednesday of each month. For this reason, we schedule our releases to happen on a first or third Thursday.
  +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.
  +
  +We plan each release about 8 weeks in advance. At this stage, the final feature set is not etched in stone but a number of priority features/improvements is identified (via discussion on the mailinglist and/or via issue tracker comments and PRs) and scheduled. A first draft of a release plan is created by the project lead on the https://projects.eclipse.org/projects/technology.rdf4j[Eclipse RDF4J project site], and the necessary milestones are created in the https://github.com/eclipse/rdf4j/issues[RDF4J issue tracker]. In addition, the https://github.com/eclipse/rdf4j/projects/2[next minor release planning board] is updated.
   
   === Review planning and application
  +
  +A release can only be done once its review is successfully concluded. Eclipse release review are announced in regular cycles, and always complete on the first or third Wednesday of each month. For this reason, we schedule our releases to happen on a first or third Thursday.
   
   A release review runs for a week. Although mostly a formality, it does need some careful preparation and planning. It needs to be formally applied for, and this application in turn requires that several pieces of documentation are in order:
   
  
positive.code:     git tag 2.1.6
      git push -u origin 2.1.6
  
  == Release distribution deployment
  
  RDF4J has two separate distributions:
  
negative.code: +
      git push -u origin releases/2.1.6
  
  Bug fixes are typically added to a hotfix release branch by https://git-scm.com/docs/git-cherry-pick[cherry-picking] the relevant commits from the _master_ branch. 
  
  This works as follows:
  
  