diff --git a/docs/en/05_Contributing/04_Making_A_SilverStripe_Core_Release.md b/docs/en/05_Contributing/04_Making_A_SilverStripe_Core_Release.md index dcea774a3..0fd5e9587 100644 --- a/docs/en/05_Contributing/04_Making_A_SilverStripe_Core_Release.md +++ b/docs/en/05_Contributing/04_Making_A_SilverStripe_Core_Release.md @@ -91,7 +91,7 @@ When doing a security release, typically one or more (or sometimes all) of the b steps will need to be performed manually. As such, this guide should not be followed exactly the same for these. -Standard practice is to produce an RC for any patched modules on the security +Standard practice is to produce a pre-release for any patched modules on the security forks for cms and framework (see [silverstripe-security](https://github.com/silverstripe-security)).
@@ -117,8 +117,8 @@ Producing a security fix follows this general process: * 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 applied to this branch only. Once a fix (or fixes) have been applied to this branch, then - an RC tag can be applied, and a private release can then be developed in order - to test this RC. + a tag can be applied, and a private release can then be developed in order + to test this release. * 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 as per normal. Make sure to publish any draft security pages at the same time as the release is published (same day). @@ -131,16 +131,16 @@ can be published as soon as a workaround or usable resolution exists. ## Standard release process -The release process, at a high level, involves creating an RC, publishing it, and -reviewing the need for either another RC or a final stable tag within a short period +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 RC cycle a temporary RC branch is created, and should only receive -absolutely critical fixes during the RC cycle. Any changes to this branch should -result in the requirement for a new RC, thus a higher level of scrutiny is typically +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 RC or stable, the following process is broken down into two +When creating a new pre-release or stable, the following process is broken down into two main sets of commands: ### Stage 1: Release preparation: @@ -168,7 +168,7 @@ This command has the following parameters: newest 3.2.x version). You can normally leave this out for patch releases, and the code will normally be able to guess the right version, but you may as well declare it every time. -* `--branch-auto` Will automatically create a new RC branch (e.g. 3.2.4) if +* `--branch-auto` Will automatically create a new temporary release branch (e.g. 3.2.4) if one does not exist. This can take between 5-15 minutes, and will invoke the following steps, @@ -180,10 +180,10 @@ and needs to be manually advanced): will look at the available versions and branch-aliases of silverstripe/installer to determine the best version to install from. E.g. installing 4.0.0 will know to install dev-master, and installing 3.3.0 will install from 3.x-dev. - If installing RC versions for stabilisation, it will use the correct RC - branch. + If installing pre-release versions for stabilisation, it will use the correct + temporary release branch. * `release:branch` If release:create installed from a non-rc branch, it will - create the new RC branch (via `--branch-auto`). You can also customise this branch + create the new temporary release branch (via `--branch-auto`). You can also customise this branch with `--branch=`, 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 [api:i18nTextCollector] task will be invoked @@ -235,7 +235,7 @@ 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:push` The RC branches and all tags are pushed up to origin on github. +* `release:push` The temporary release branches and all tags are pushed up to origin 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 @@ -252,11 +252,11 @@ Once all of these commands have completed there are a couple of final tasks left aren't strictly able to be automated: * If this is a stable release, it will be necessary to perform a post-release merge - on open source. This normally will require you to merge the RC branch into the + 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. E.g. branching 3.3 from 3, and aliasing 3 as 3.4.x-dev. You can then delete - the temporary RC branches. This will need to be done before updating the + the temporary release branches. This will need to be done before updating the release documentation in stage 3. * Merging up the changes in this release to newer branches, following the SemVer pattern (e.g. 3.2.4 > 3.2 > 3.3 > 3 > master). The more often this is @@ -298,7 +298,7 @@ will need to be regularly updated. * Make sure that the [download page](http://www.silverstripe.org/download) on silverstripe.org has the release available. If it's a stable, it will appear - at the top of the page. If an RC pre-release, it will be available under the + at the top of the page. If it's a pre-release, it will be available under the [development builds](http://www.silverstripe.org/download#download-releases) section. If it's not available, you might need to check that the release was properly uploaded to aws s3, or that you aren't viewing a cached version of