Improve release process instructions

docs/en/05_Contributing/04_Making_A_SilverStripe_Core_Release.md

@@ -119,8 +119,14 @@ Producing a security fix follows this general process:
   an RC tag can be applied, and a private release can then be developed in order
   to test this RC.
 * Once RC testing is completed and the release is ready for stabilisation, then these fixes
-  can then be pushed to the upstream module fork, and the release completed and published
+  can then be pushed to the upstream module fork, and the release completed as per normal.
-  as per normal.
+  Make sure to publish any draft security pages at the same time as the release is published (same day).
+
+<div class="warning" markdown="1">
+Note: It's not considered acceptable to disclose any security vulnerability until a fix exists in
+a public stable, not an RC or dev-branch. Security warnings that do not require a stable release
+can be published as soon as a workaround or usable resolution exists.
+</div>
 
 ## Standard release process
 
@@ -138,6 +144,13 @@ main sets of commands:
 
 ### Stage 1: Release preparation:
 
+If you are managing a release, it's best to first make sure that SilverStripe marketing
+are aware of any impending release. This is so that they can ensure that a relevant blog
+post will appear on [www.silverstripe.org/blog](http://www.silverstripe.org/blog/), and
+cross-posted to other relevant channels such as Twitter and Facebook.
+Make sure Nicole and Vinh at silverstripe at aware by sending an email to
+[marketing@silverstripe.com](mailto:marketing@silverstripe.com).
+
 This is the part of the release that prepares and tests everything locally, but
 doe not make any upstream changes (so it's safe to run without worrying about
 any mistakes migrating their way into the public sphere).
@@ -197,6 +210,13 @@ It's also ideal to eyeball the git changes generated by the release tool, making
 that no translation strings were unintentionally lost, or that the changelog
 was generated correctly.
 
+In particular, double check that all necessary information is included in the release notes,
+including:
+
+* Upgrading notes
+* Security fixes included
+* Major changes
+
 Once this has been done, then the release is ready to be published live.
 
 ### Stage 2: Release publication
@@ -251,6 +271,25 @@ aren't strictly able to be automated:
 * Make sure that the [releases page](https://github.com/silverstripe/silverstripe-installer/releases)
   on github shows the new tag.
 
+*Updating non-patch versions*
+
+If releasing a new major or minor version it may be necessary to update various SilverStripe portals. Normally a new
+minor version will require a new branch option to be made available on each site menu. These sites include:
+
+* [docs.silverstripe.org](https://docs.silverstripe.org): Update on [github](https://github.com/silverstripe/doc.silverstripe.org)
+  and deployed internally.
+* [api.silverstripe.org](https://api.silverstripe.org): Update on [github](https://github.com/silverstripe/api.silverstripe.org)
+  and deployed internally.
+* [userhelp.silverstripe.org](https://userhelp.silverstripe.org/en/3.2): Update on
+  [github](https://github.com/silverstripe/userhelp.silverstripe.org) and deployed internally.
+  The content for this site is pulled from [silverstripe-userhelp-content](https://github.com/silverstripe/silverstripe-userhelp-content)
+* [demo.silverstripe.org](http://demo.silverstripe.org/): Update on
+  [github](https://github.com/silverstripe/demo.silverstripe.org/) and deployed internally.
+
+It's also a good idea to check that `Deprecation::notification_version('4.0.0');` in framework/_config.php points to
+the right major version. This should match the major version of the current release. E.g. all versions of 4.x
+should be set to `4.0.0`.
+
 ### Stage 3: Let the world know
 
 Once a release has been published there are a few places where user documentation