tonyair/silverstripe-framework
1
0
Fork 0
mirror of https://github.com/silverstripe/silverstripe-framework synced 2024-10-22 14:05:37 +02:00
Code Issues Projects Releases Wiki Activity

Clarify RC wording in release docs

Browse Source 
An RC is technically only one of a few "pre-release" labels (alpha, beta, rc)
This commit is contained in:
Ingo Schommer 2015-12-21 13:30:36 +13:00
parent 7c3fd7de13
commit ce1a069885
1 changed files with 17 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
docs/en/05_Contributing/04_Making_A_SilverStripe_Core_Release.md
View File

@ -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 steps will need to be performed manually. As such, this guide should not be followed
exactly the same for these. 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)). forks for cms and framework (see [silverstripe-security](https://github.com/silverstripe-security)).
<div class="warning" markdown="1"> <div class="warning" markdown="1">
@ -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 * 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 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 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 a tag can be applied, and a private release can then be developed in order
to test this RC. to test this release.
* Once RC testing is completed and the release is ready for stabilisation, then these fixes * 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. 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). 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 ## Standard release process
The release process, at a high level, involves creating an RC, publishing it, and The release process, at a high level, involves creating a release, publishing it, and
reviewing the need for either another RC or a final stable tag within a short period reviewing the need for either another pre-release or a final stable tag within a short period
(normally within 3-5 business days). (normally within 3-5 business days).
During the RC cycle a temporary RC branch is created, and should only receive During the pre-release cycle a temporary branch is created, and should only receive
absolutely critical fixes during the RC cycle. Any changes to this branch should absolutely critical fixes during the cycle. Any changes to this branch should
result in the requirement for a new RC, thus a higher level of scrutiny is typically result in the requirement for a new release, thus a higher level of scrutiny is typically
placed on any pull request to these branches. 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: main sets of commands:
### Stage 1: Release preparation: ### 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, 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 and the code will normally be able to guess the right version, but you may
as well declare it every time. 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. one does not exist.
This can take between 5-15 minutes, and will invoke the following steps, 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 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 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. 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 If installing pre-release versions for stabilisation, it will use the correct
branch. temporary release branch.
* `release:branch` If release:create installed from a non-rc branch, it will * `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=<branchname>`, but it's best to use the standard. with `--branch=<branchname>`, but it's best to use the standard.
* `release:translate` All upstream transifex strings will be pulled into the * `release:translate` All upstream transifex strings will be pulled into the
local master strings, and then the [api:i18nTextCollector] task will be invoked 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: 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).
* `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 * `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 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 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: aren't strictly able to be automated:
* If this is a stable release, it will be necessary to perform a post-release merge * 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 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. 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 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. release documentation in stage 3.
* Merging up the changes in this release to newer branches, following the * 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 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 * 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 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) [development builds](http://www.silverstripe.org/download#download-releases)
section. If it's not available, you might need to check that the release was 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 properly uploaded to aws s3, or that you aren't viewing a cached version of