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: 
  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: 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.
  
  