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

DOCS Update "release numbering" to document the fact that lock step releases are not required (#9000)

Browse Source 
* 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]
This commit is contained in:
Robbie Averill 2019-05-22 10:16:24 +12:00 committed by Ingo Schommer
parent b9a8f64ef0
commit e948c5eb1e
2 changed files with 17 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
docs/en/05_Contributing/04_Release_Process.md
View File

@ -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:

12
docs/en/05_Contributing/05_Making_A_SilverStripe_Core_Release.md
View File

@ -265,7 +265,7 @@ E.g.
`cow release 4.0.1 -vvv`
* `<version>` The version that is to be released. E.g. `4.1.4` or `4.3.0-rc1`
* `<version>` The recipe 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):
@ -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=<branchname>`, 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