anchor.diff:  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
  +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
  
positive.code: 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.
  
negative.code: release deployment. Once release deployment is complete, the release branch
  is deleted.
  
  IMPORTANT: 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
  