anchor.diff:  
   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.
  +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/pulls[RDF4J Pull Requests] milestones are updated as the code is ready for inclusion.
   
   === Review planning and application
   
  
positive.code: branch is deleted.
  
  IMPORTANT: It is important that only features and fixes that have already been scheduled
  for release (via milestone labels) 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).
  
negative.code: 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.
  The milestone label of the issue is set to the *planned* release version for the
  issue, but that could change by the time a PR is merged.
  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.
  
  