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

Add semver reference in core committers guide

Browse Source
This commit is contained in:
Sam Minnée 2018-05-21 14:08:52 +12:00 committed by GitHub
parent 7b6f4c0a53
commit 4ccacf509f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
docs/en/05_Contributing/09_Core_committers.md
View File

@ -27,6 +27,7 @@ With great power comes great responsibility, so we have agreed on certain expect
* Only merge code you have tested and fully understand. If in doubt, ask for a second opinion. * Only merge code you have tested and fully understand. If in doubt, ask for a second opinion.
* Ensure contributions have appropriate [test coverage](../developer_guides/testing), are documented, and pass our [coding conventions](/getting_started/coding_conventions) * Ensure contributions have appropriate [test coverage](../developer_guides/testing), are documented, and pass our [coding conventions](/getting_started/coding_conventions)
* Keep the codebase "releasable" at all times (check our [release process](release_process)) * Keep the codebase "releasable" at all times (check our [release process](release_process))
* Follow [Semantic Versioning](code/#picking-the-right-version) by putting any changes into the correct branch
* API changes and non-trivial features should not be merged into release branches. * API changes and non-trivial features should not be merged into release branches.
* API changes on master should not be merged until they have the buy-in of at least two Core Committers (or better, through the [core mailing list](https://groups.google.com/forum/#!forum/silverstripe-dev)) * API changes on master should not be merged until they have the buy-in of at least two Core Committers (or better, through the [core mailing list](https://groups.google.com/forum/#!forum/silverstripe-dev))
* Be inclusive. Ensure a wide range of SilverStripe developers can obtain an understanding of your code and docs, and you're not the only one who can maintain it. * Be inclusive. Ensure a wide range of SilverStripe developers can obtain an understanding of your code and docs, and you're not the only one who can maintain it.