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

Merge pull request #9392 from creative-commoners/pulls/4/document-tweak-releases

Browse Source 
DOC Add documentation for tweak releases
This commit is contained in:
Steve Boyd 2020-02-03 15:33:36 +13:00 committed by GitHub
commit 566b81f326
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 34 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -231,11 +231,11 @@ each release, if making multiple releases.
## Standard release process ## Standard release process
The release process, at a high level, involves creating a release, publishing it, and See [Release Process](release-process) for details on the standard timeline for releases.
reviewing the need for either another pre-release or a final stable tag within a short period In summary, we produce a beta release, stabilise, produce a release candidate, perform
(normally within 3-5 business days). penetration testing, and then produce a stable release.
When creating a new pre-release or stable, the following process is broken down into two When creating a new release, the following process is broken down into two
main sets of commands: main sets of commands:
### Stage 1: Release preparation: ### Stage 1: Release preparation:
@ -324,6 +324,36 @@ and needs to be manually advanced):
links to the security registrar (http://www.silverstripe.org/download/security-releases) links to the security registrar (http://www.silverstripe.org/download/security-releases)
match the pages saved in draft. match the pages saved in draft.
#### Basing a new release on a previous one (tweak releases)
Commonly a stable release will need to mirror the contents of the release
candidate that preceded it, sometimes with a small set of additional commits.
However, running the standard `cow release` command will create a release that
includes all the latest commits on the branches it targets, which can include
unaudited code. A **tweak release** includes only the commits present in the
previous tagged release by default, and can optionally include additional
commits when necessary. To create one, use the `release:detach-tagged-base`
command:
1. `cow release:create <new-version>` to create the new release.
2. `cow release:plan <new-version>` to generate a plan for the new release.
3. `cow release:detach-tagged-base <new-version>` to shift all of the modules
to the correct commit in the branch to match the contents of the last release.
* **How?** This command finds the last common commit between the latest tag on
the chosen branch and the tip of that branch, and then shifts the HEAD to
that commit.
4. `cherry-pick` any extra commits that need to be included in the release onto
the affected module(s).
5. Run usual release preparation commands (from `release:test` onwards).
6. Publish the release.
Any extra commits included in a tweak release should be applied to the release
branch as soon as possible (if they weren't cherry-picked from it). Avoid
merging the tagged release into the branch to achieve this, as this will include
the release commit, which may pin Composer dependencies to specific versions.
#### Testing the release
Once the release task has completed, it may be ideal to manually test the site out Once the release task has completed, it may be ideal to manually test the site out
by running it locally (e.g. `http://localhost/release-3.3.4`) to do some smoke-testing by running it locally (e.g. `http://localhost/release-3.3.4`) to do some smoke-testing
and make sure that there are no obvious issues missed. and make sure that there are no obvious issues missed.