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

Some minor sentence rewording

Browse Source 
Co-Authored-By: Bryn Whyman <bryn.whyman@silverstripe.com>
This commit is contained in:
Maxime Rainville 2020-01-07 10:08:32 +13:00 committed by GitHub
parent 3f15957b5f
commit d9f48e76bc
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -17,7 +17,7 @@ module in a "potentially releasable" state. Releases are planned around an issue
[roadmap](https://www.silverstripe.org/software/roadmap/). We re-revaluate our priorities every few weeks. [roadmap](https://www.silverstripe.org/software/roadmap/). We re-revaluate our priorities every few weeks.
Silverstripe CMS is split up into many modules listed on [github.com/silverstripe](https://github.com/silverstripe). Silverstripe CMS is split up into many modules listed on [github.com/silverstripe](https://github.com/silverstripe).
Each of them will have its own milestones and issues, and different release lines (e.g. 1.x vs. 4.x). Each may have a different release line (e.g. 1.x vs. 4.x).
There are high-level "recipe" milestones on the [framework repository](https://github.com/silverstripe/silverstripe-framework/milestones) There are high-level "recipe" milestones on the [framework repository](https://github.com/silverstripe/silverstripe-framework/milestones)
to combine individual module milestones into a larger release that's eventually available to install with to combine individual module milestones into a larger release that's eventually available to install with
[composer](https://silverstripe.org/download). [composer](https://silverstripe.org/download).
@ -47,7 +47,7 @@ versions of its modules within the same minor release line (4.3 in this example)
## Regular quarterly releases ## Regular quarterly releases
A regular Silverstripe CMS release is tagged every quarter. This usually involves creating a new minor increment of A regular Silverstripe CMS release is tagged on a quarterly basis, in the months: March, June, September, December. This usually involves creating a new minor increment of
each core recipe. Regular quarterly releases are preceded by pre-stable releases to help lay the groundwork for the each core recipe. Regular quarterly releases are preceded by pre-stable releases to help lay the groundwork for the
stable release. stable release.
@ -63,7 +63,7 @@ testers.
#### "Beta release" definition #### "Beta release" definition
The purpose of a beta release is to stabilise the Silverstripe CMS codebase for an upcoming stable release and showcase The purpose of a beta release is to initiate a "Feature Freeze" to stabilise the Silverstripe CMS codebase for an upcoming stable release and showcase
new features. A beta release is likely to contain regressions and new bugs. A beta release is primarily aimed at testers new features. A beta release is likely to contain regressions and new bugs. A beta release is primarily aimed at testers
who want to help identify bugs and regressions. who want to help identify bugs and regressions.
@ -152,7 +152,7 @@ How to deprecate an API:
* Make sure that the old deprecated function works by calling the new function - don't have duplicated code! * Make sure that the old deprecated function works by calling the new function - don't have duplicated code!
* The commit message should contain an `API` prefix (see ["commit message format"](code#commit-messages)) * The commit message should contain an `API` prefix (see ["commit message format"](code#commit-messages))
* Document the change in the [changelog](/changelogs) for the next release * Document the change in the [changelog](/changelogs) for the next release
* Deprecated APIs can be removed only after developers have had sufficient time to react to the changes. Hence, deprecated APIs should be removed in MAJOR releases only. Between MAJOR releases, leave the code in place with a deprecation warning. * Deprecated APIs can be removed only after developers have had sufficient time to react to the changes. Hence, deprecated APIs should be removed in MAJOR releases only. Between MAJOR releases, leave the code in place with a deprecation warning.
* Exceptions to the deprecation cycle are APIs that have been moved into their own module, and continue to work with the new minor release. These changes can be performed in a single minor release without a deprecation period. * Exceptions to the deprecation cycle are APIs that have been moved into their own module, and continue to work with the new minor release. These changes can be performed in a single minor release without a deprecation period.
* Add a `warnings` entry to the module's `.upgrade.yml` file so the * Add a `warnings` entry to the module's `.upgrade.yml` file so the
[Silverstripe Upgrader can flag deprecated APIs](/upgrading/upgrading_module#upgradeyml). [Silverstripe Upgrader can flag deprecated APIs](/upgrading/upgrading_module#upgradeyml).