From e948c5eb1e4944916de43435c25abfe1ba97d722 Mon Sep 17 00:00:00 2001 From: Robbie Averill Date: Wed, 22 May 2019 10:16:24 +1200 Subject: [PATCH] DOCS Update "release numbering" to document the fact that lock step releases are not required (#9000) * DOCS Update "release numbering" to document the fact that lock step releases are not required [ci skip] * DOCS Update "making a SilverStripe core release" to clarify recipe versus module without lock step Also adds note about peer reviewing the plan before release [ci skip] --- docs/en/05_Contributing/04_Release_Process.md | 10 +++++++++- .../05_Making_A_SilverStripe_Core_Release.md | 12 ++++++++---- 2 files changed, 17 insertions(+), 5 deletions(-) diff --git a/docs/en/05_Contributing/04_Release_Process.md b/docs/en/05_Contributing/04_Release_Process.md index 0150ad6c0..8e90b15c7 100644 --- a/docs/en/05_Contributing/04_Release_Process.md +++ b/docs/en/05_Contributing/04_Release_Process.md @@ -27,10 +27,18 @@ Release dates are usually not published prior to the release, but you can get a reviewing the release milestone on github.com. Releases will be announced on the ["releases" forum category](https://forum.silverstripe.org/c/releases). -## Release Numbering +## Release numbering {#release-numbering} SilverStripe follows [Semantic Versioning](http://semver.org). +All SilverStripe modules (including silverstripe/framework) may have patch releases created at any time, and will +not necessarily match other core module patch release numbers. For example, your project may be using +silverstripe/cms 4.3.1 with silverstripe/versioned 4.3.9. + +All SilverStripe recipes are released in lock step with each other. For example, silverstripe/installer 4.3.1 will +contain silverstripe/recipe-cms 4.3.1 and silverstripe/recipe-core 4.3.1. These recipes may contain various patch +versions of its modules within the same minor release line (4.3 in this example). + ## Supported versions {#supported-versions} At any point in time, the core development team will support a set of releases to varying levels: diff --git a/docs/en/05_Contributing/05_Making_A_SilverStripe_Core_Release.md b/docs/en/05_Contributing/05_Making_A_SilverStripe_Core_Release.md index 3da1232ed..afbff7a02 100644 --- a/docs/en/05_Contributing/05_Making_A_SilverStripe_Core_Release.md +++ b/docs/en/05_Contributing/05_Making_A_SilverStripe_Core_Release.md @@ -265,7 +265,7 @@ E.g. `cow release 4.0.1 -vvv` -* `` The version that is to be released. E.g. `4.1.4` or `4.3.0-rc1` +* `` The recipe version that is to be released. E.g. `4.1.4` or `4.3.0-rc1` * `` `Optional: the recipe that is being released (default: "silverstripe/installer") This command has these options (note that --repository option is critical for security releases): @@ -296,8 +296,10 @@ and needs to be manually advanced): 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. + and determines what new versions of those dependencies need to be tagged to create the final release. Note that + the patch version numbers of each module may differ. This step requires the latest versions to be released are + determined and added to the plan. 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=`, but it's best to use the standard. @@ -327,7 +329,7 @@ Since `cow` will only run the unit test suite, you'll need to check 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 +It's also ideal to eyeball the Git changes generated by the release tool, making sure that no translation strings were unintentionally lost, and that the changelog was generated correctly. In particular, double check that all necessary information is included in the release notes, @@ -337,6 +339,8 @@ including: * Security fixes included * Major changes +Before publication, ensure that the release plan has been peer reviewed by another member of the core team. + Once this has been done, then the release is ready to be published live. ### Stage 2: Release publication