Merge branch '4.1' into 4.2

# Conflicts:
 #	docs/en/05_Contributing/05_Making_A_SilverStripe_Core_Release.md

docs/en/04_Changelogs/4.0.6.md

@@ -0,0 +1,19 @@
+# 4.0.6
+
+<!--- Changes below this line will be automatically regenerated -->
+
+## Change Log
+
+### Security
+
+ * 2018-12-10 [0e841aa](https://github.com/silverstripe/silverstripe-graphql/commit/0e841aabb7372d9fa78108e4819e151608ddec0f) Apply CSRF middlware API
+ * 2018-11-07 [48bd33564](https://github.com/silverstripe/silverstripe-framework/commit/48bd335648188df9dae72be1e5f9c808f3fe1e77) Ensure that table names are escaped to prevent possible SQL injection (Robbie Averill) - See [ss-2018-020](https://www.silverstripe.org/download/security-releases/ss-2018-020)
+ 
+### Bugfixes
+
+ * 2018-11-29 [59221e8](https://github.com/silverstripe/silverstripe-assets/commit/59221e8d74ac5e07b86a741e2709e0676130f7b4) Cache key cannot contain : chars, will happen when viewing from archive (Robbie Averill)
+ * 2018-11-21 [9ce6d91b7](https://github.com/silverstripe/silverstripe-framework/commit/9ce6d91b76e525a6fc81e02023e9e53cdf82e047) / TreeMultiselectField::objectForKey handles list of IDs correctly (Serge Latyntcev)
+ * 2018-11-16 [35c3a8c6](https://github.com/silverstripe/silverstripe-cms/commit/35c3a8c68db2660838dcd2ae5abd2bd1c3214af4) 'Search' text in default search form should be a placeholder (Robbie Averill)
+ * 2018-11-15 [b5bae137b](https://github.com/silverstripe/silverstripe-framework/commit/b5bae137bd341eeda3f4886f45fc8f8d657a9c4c) Redirect loop with multiple confirmation tokens present (fixes #8607) (Loz Calver)
+ * 2018-11-12 [15aaf9db9](https://github.com/silverstripe/silverstripe-framework/commit/15aaf9db9fe1679cf8b01b74fce3eee841278495) Fix a code style typo (Serge Latyntcev)
+ * 2018-11-08 [4b4fbabed](https://github.com/silverstripe/silverstripe-framework/commit/4b4fbabed5d70bf577e4b0d6fdbc9dab9da80451) TreeMultiselectField passes value 'unchanged' as null to ORM for 'ID' column key (Serge Latyntcev)

docs/en/05_Contributing/05_Making_A_SilverStripe_Core_Release.md

@@ -28,7 +28,10 @@ As a core contributor it is necessary to have installed the following set of too
 * [cow release tool](https://github.com/silverstripe/cow#install). This should typically
   be installed in a global location via the below command. Please see the installation
   docs on the cow repo for more setup details.
-  `composer global require silverstripe/cow dev-master`
+  `composer global require silverstripe/cow ^2`
+* [satis repository tool](https://github.com/composer/satis). This should be installed
+  globally for minimum maintenance.
+  `composer global require composer/satis ^1`
 * [transifex client](http://docs.transifex.com/client/).
   `pip install transifex-client`
   If you're on OSX 10.10+, the standard Python installer is locked down.
@@ -115,10 +118,14 @@ Producing a security fix follows this general process:
   release date of the final stable is not known, then it's ok to give an estimated
   release schedule.
 * Push the current upstream target branches (e.g. 3.2) to the corresponding security fork
-  to a new branch named for the target release (e.g. 3.2.4). Security fixes should be 
+  to the equivalent branch on [silverstripe-security](https://github.com/silverstripe-security).
-  applied to this branch only. Once a fix (or fixes) have been applied to this branch, then
+  Security fixes should be applied to the branch on this private repository only.
-  a tag can be applied, and a private release can then be developed in order
+  Once a fix (or fixes) have been applied to this branch, then a tag can be applied,
-  to test this release.
+  and a private release can then be developed in order to test this release.
+* Once upstream branches are all pushed to the security forks, make sure to merge all
+  security fixes into those branches prior to running cow.
+* Setup a temporary [satis](https://github.com/composer/satis) repository which points to all relevant repositories
+  containing security fixes. See below for setting up a temporary satis repository.
 * Once release 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 as per normal.
   Make sure to publish any draft security pages at the same time as the release is published (same day).
@@ -131,17 +138,64 @@ a public stable, not an RC or dev-branch. Security warnings that do not require
 can be published as soon as a workaround or usable resolution exists.
 </div>
 
+### Setting up satis for hosting private security releases
+
+When installing a project from protected repositories, it's necessary prior to creating your project
+to override the public repository URLs with the private repositories containing undisclosed fixes. For
+this we use [satis](https://github.com/composer/satis).
+
+To setup a Satis project for a release:
+
+* Ensure Satis is installed globally: `composer global require composer/satis ^1` 
+* `cd ~/Sites/` (or wherever your web-root is located)
+* `mkdir satis-security && cd satis-security` (or some directory specific to your release)
+* Create a config file (e.g. config.json) of the given format (add only those repositories necessary).
+
+Note:
+- The homepage path should match the eventual location of the package content
+- You should add the root repository (silverstripe/installer) to ensure
+ `create-project` works (even if not a private security fork).
+- You should add some package version constraints to prevent having to parse
+ all legacy tags and all branches.
+
+```json
+{
+    "name": "SilverStripe Security Repository",
+    "homepage": "http://localhost/satis-security/public",
+    "repositories": {
+        "installer": {
+            "type": "vcs",
+            "url": "https://github.com/silverstripe/silverstripe-installer.git"
+        },
+        "framework": {
+            "type": "vcs",
+            "url": "https://github.com/silverstripe-security/silverstripe-framework.git"
+        }
+    },
+    "require": {
+		"silverstripe/installer": "^3.5 || ^4",
+		"silverstripe/framework": "^3.5 || ^4"
+	},
+    "require-all": true
+}
+```
+
+* Build the repository:
+  `satis build config.json ./public`
+* Test you can view the satis home page at `http://localhost/satis-security/public/`
+* When performing the release ensure you use `--repository=http://localhost/satis-security/public` (below)
+
+<div class="warning" markdown="1">
+It's important that you re-run `satis build` step after EVERY change that is pushed upstream; E.g. between
+each release, if making multiple releases.
+</div>
+
 ## Standard release process
 
 The release process, at a high level, involves creating a release, publishing it, and
 reviewing the need for either another pre-release or a final stable tag within a short period
 (normally within 3-5 business days).
 
-During the pre-release cycle a temporary branch is created, and should only receive
-absolutely critical fixes during the cycle. Any changes to this branch should
-result in the requirement for a new release, thus a higher level of scrutiny is typically
-placed on any pull request to these branches.
-
 When creating a new pre-release or stable, the following process is broken down into two
 main sets of commands:
 
@@ -161,7 +215,7 @@ Check all tickets assigned to that milestone are either closed or reassigned to
 Use the [list of all issues across modules](https://www.silverstripe.org/community/contributing-to-silverstripe/github-all-core-issues)
 as a starting point, and add a `milestone:"your-milestone"` filter.
 
-Merge up from other older supported release branches (e.g. merge `3.1`->`3.2`, `3.2`->`3.3`, `3.3`->`3`, `3`->`master`).
+Merge up from other older supported release branches (e.g. merge `4.0`->`4.1`, `4.1`->`4.2`, `4.2`->`4`, `4`->`master`).
 
 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
@@ -169,13 +223,30 @@ any mistakes migrating their way into the public sphere).
 
 Invoked by running `cow release` in the format as below:
 
-```
+`cow release <version> [recipe] -vvv`
-cow release <version> -vvv
-```
 
-This command has the following parameters:
+E.g.
 
-* `<version>` The version that is to be released. E.g. 3.2.4 or 4.0.0-alpha4
+`cow release 4.0.1 -vvv`
+
+* `<version>` The version that is to be released. E.g. `4.1.4` or `4.3.0-rc1`
+* `<recipe>` `Optional: the recipe that is being released (default: "silverstripe/installer")
+
+This command has these options (note that --repository option is critical for security releases):
+
+* `-vvv` to ensure all underlying commands are echoed
+* `--directory <directory>` to specify the folder to create or look for this project in. If you don't specify this,
+it will install to the path specified by `./release-<version>` in the current directory.
+* `--repository <repository>` will allow a custom composer package url to be specified. E.g. `http://packages.cwp.govt.nz`
+  See the above section "Setting up satis for hosting private security releases" on how to prepare a custom
+  repository for a security release.
+* `--branching <type>` will specify a branching strategy. This allows these options:
+  * `auto` - Default option, will branch to the minor version (e.g. 1.1) unless doing a non-stable tag (e.g. rc1)
+  * `major` - Branch all repos to the major version (e.g. 1) unless already on a more-specific minor version.
+  * `minor` - Branch all repos to the minor semver branch (e.g. 1.1)
+  * `none` - Release from the current branch and do no branching.
+* `--skip-tests` to skip tests
+* `--skip-i18n` to skip updating localisations
 
 This can take between 5-15 minutes, and will invoke the following steps,
 each of which can also be run in isolation (in case the process stalls
@@ -188,14 +259,17 @@ and needs to be manually advanced):
   know to install dev-master, and installing 3.3.0 will install from 3.x-dev.
   If installing pre-release versions for stabilisation, it will use the correct
   temporary release branch.
+* `release:plan` The release planning will take place, this reads the various dependencies of the recipe being released
+  and determines what new versions of those dependencies need to be tagged to create the final release. The conclusion
+  of the planning step is output to the screen and requires user confirmation.
 * `release:branch` If release:create installed from a non-rc branch, it will
   create the new temporary release branch (via `--branch-auto`). You can also customise this branch
   with `--branch=<branchname>`, but it's best to use the standard.
 * `release:translate` All upstream transifex strings will be pulled into the
-  local master strings, and then the [i18nTextCollector](api:SilverStripe\i18n\TextCollection\i18nTextCollector) task will be invoked
+  local master strings, and then the [i18nTextCollector](api:SilverStripe\i18n\TextCollection\i18nTextCollector)
-  and will merge these strings together, before pushing all new master strings
+  task will be invoked and will merge these strings together, before pushing all
-  back up to transifex to make them available for translation. Changes to these
+  new master strings back up to transifex to make them available for translation.
-  files will also be automatically committed to git.
+  Changes to these files will also be automatically committed to git.
 * `release:test` Will run all unit tests on this release. Make sure that you
   setup your `.env` correctly (as above) so that this will work.
 * `release:changelog` Will compare the current branch head with `--from` parameter
@@ -218,9 +292,7 @@ the build status of Behat end-to-end tests manually on travis-ci.org.
 Check the badges on the various modules available on [github.com/silverstripe](http://github.com/silverstripe).
 
 It's also ideal to eyeball the git changes generated by the release tool, making sure
-that no translation strings were unintentionally lost, no malicious changes were
+that no translation strings were unintentionally lost, and that the changelog was generated correctly.
-introduced in the (community contributed) translations, and that the changelog
-was generated correctly.
 
 In particular, double check that all necessary information is included in the release notes,
 including:
@@ -240,14 +312,29 @@ building an archive, and uploading to
 
 Invoked by running `cow release:publish` in the format as below:
 
-```
+`cow release:publish <version> [<recipe>] -vvv`
-cow release:publish <version> -vvv
+
-```
+E.g.
+
+`cow release:publish 4.0.1 silverstripe/installer`
+
+This command has these options:
+
+* `-vvv` to ensure all underlying commands are echoed
+* `--directory <directory>` to specify the folder to look for the project created in the prior step. As with
+  above, it will be guessed if omitted. You can run this command in the `./release-<version>` directory and
+  omit this option.
+* `--aws-profile <profile>` to specify the AWS profile name for uploading releases to s3. Check with
+  damian@silverstripe.com if you don't have an AWS key setup.
+* `--skip-archive-upload` to disable both "archive" and "upload". This is useful if doing a private release and
+  you don't want to upload this file to AWS.
+* `--skip-upload` to disable the "upload" command (but not archive)
+
 As with the `cow release` command, this step is broken down into the following
 subtasks which are invoked in sequence:
 
-* `release:tag` Each module will have the appropriate tag applied (except the theme).
+* `release:tag` Each module will have the appropriate tag applied (except the theme). All tags are pushed up to origin
-* `release:push` The temporary release branches and all tags are pushed up to origin on github.
+  on github.
 * `release:archive` This will generate a new tar.gz and zip archive, each for
   cms and framework-only installations. These will be copied to the root folder
   of the release directory, although the actual build will be created in temporary
@@ -264,7 +351,7 @@ subtasks which are invoked in sequence:
 Once all of these commands have completed there are a couple of final tasks left that
 aren't strictly able to be automated:
 
-* If this is a stable release, it will be necessary to perform a post-release merge
+* It will be necessary to perform a post-release merge
   on open source. This normally will require you to merge the temporary release branch into the
   source branch (e.g. merge 3.2.4 into 3.2), or sometimes create new branches if
   releasing a new minor version, and bumping up the branch-alias in composer.json.
@@ -275,7 +362,7 @@ aren't strictly able to be automated:
   SemVer pattern (e.g. 3.2.4 > 3.2 > 3.3 > 3 > master). The more often this is
   done the easier it is, but this can sometimes be left for when you have
   more free time. Branches not receiving regular stable versions anymore (e.g.
-  3.0 or 3.1) should usually be omitted.
+  3.0 or 3.1) can be omitted.
 * Set the github milestones to completed, and create placeholders for the next
   minor versions. It may be necessary to re-assign any issues assigned to the prior
   milestones to these new ones.