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 #4871 from tractorcow/pulls/3.2/better-release-instructions

Browse Source 
Improve release process instructions
This commit is contained in:
Sam Minnée 2015-12-23 16:50:46 +13:00
commit 751264fd6a
1 changed files with 41 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -119,8 +119,14 @@ Producing a security fix follows this general process:
an RC tag can be applied, and a private release can then be developed in order
to test this RC.
* 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 and published
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).
<div class="warning" markdown="1">
Note: It's not considered acceptable to disclose any security vulnerability until a fix exists in
a public stable, not an RC or dev-branch. Security warnings that do not require a stable release
can be published as soon as a workaround or usable resolution exists.
</div>
## Standard release process
@ -138,6 +144,13 @@ main sets of commands:
### Stage 1: Release preparation:
If you are managing a release, it's best to first make sure that SilverStripe marketing
are aware of any impending release. This is so that they can ensure that a relevant blog
post will appear on [www.silverstripe.org/blog](http://www.silverstripe.org/blog/), and
cross-posted to other relevant channels such as Twitter and Facebook.
Make sure Nicole and Vinh at silverstripe at aware by sending an email to
[marketing@silverstripe.com](mailto:marketing@silverstripe.com).
This is the part of the release that prepares and tests everything locally, but
doe not make any upstream changes (so it's safe to run without worrying about
any mistakes migrating their way into the public sphere).
@ -197,6 +210,13 @@ It's also ideal to eyeball the git changes generated by the release tool, making
that no translation strings were unintentionally lost, or that the changelog
was generated correctly.
In particular, double check that all necessary information is included in the release notes,
including:
* Upgrading notes
* Security fixes included
* Major changes
Once this has been done, then the release is ready to be published live.
### Stage 2: Release publication
@ -251,6 +271,25 @@ aren't strictly able to be automated:
* Make sure that the [releases page](https://github.com/silverstripe/silverstripe-installer/releases)
on github shows the new tag.
*Updating non-patch versions*
If releasing a new major or minor version it may be necessary to update various SilverStripe portals. Normally a new
minor version will require a new branch option to be made available on each site menu. These sites include:
* [docs.silverstripe.org](https://docs.silverstripe.org): Update on [github](https://github.com/silverstripe/doc.silverstripe.org)
and deployed internally.
* [api.silverstripe.org](https://api.silverstripe.org): Update on [github](https://github.com/silverstripe/api.silverstripe.org)
and deployed internally.
* [userhelp.silverstripe.org](https://userhelp.silverstripe.org/en/3.2): Update on
[github](https://github.com/silverstripe/userhelp.silverstripe.org) and deployed internally.
The content for this site is pulled from [silverstripe-userhelp-content](https://github.com/silverstripe/silverstripe-userhelp-content)
* [demo.silverstripe.org](http://demo.silverstripe.org/): Update on
[github](https://github.com/silverstripe/demo.silverstripe.org/) and deployed internally.
It's also a good idea to check that `Deprecation::notification_version('4.0.0');` in framework/_config.php points to
the right major version. This should match the major version of the current release. E.g. all versions of 4.x
should be set to `4.0.0`.
### Stage 3: Let the world know
Once a release has been published there are a few places where user documentation