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 note about semvar to contributing.md

Browse Source
This commit is contained in:
Will Rossiter 2014-12-04 12:14:18 +13:00
parent 369c561aa2
commit 836ea04d90
1 changed files with 20 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
CONTRIBUTING.md
View File

@ -4,9 +4,24 @@ Any open source product is only as good as the community behind it. You can part
See our [high level overview](http://silverstripe.org/contributing-to-silverstripe) on silverstripe.org on how you can help out.
Or, for more detailed guidance, read one of the following pages:
## Contributing to the correct version
* [Sharing your opinion and raising issues](http://doc.silverstripe.org/framework/en/trunk/misc/contributing/issues)
* [Providing code, whether it's creating a feature or fixing a bug](http://doc.silverstripe.org/framework/en/trunk/misc/contributing/code)
* [Writing and translating documentation](http://doc.silverstripe.org/framework/en/trunk/misc/contributing/documentation)
* [Translating user-interface elements](http://doc.silverstripe.org/framework/en/trunk/misc/contributing/translation)
SilverStripe core and module releases (since the 3.1.8 release) follow the [Semantic Versioning](http://semver.org)
(SemVar) specification for releases. Using this specification declares to the entire development community the severity
and intention of each release. It gives developers the ability to safely declare their dependencies and understand the
scope involved in each upgrade.
Each release is labeled in the format `$MAJOR`.`$MINOR`.`$PATCH`. For example, 3.1.8 or 3.2.0.
* `$MAJOR` version is incremented if any backwards incompatible changes are introduced to the public API.
* `$MINOR` version is incremented if new, backwards compatible **functionality** is introduced to the public API or
improvements are introduced within the private code.
* `$PATCH` version is incremented if only backwards compatible **bug fixes** are introduced. A bug fix is defined as
an internal change that fixes incorrect behavior.
Git Branches are setup for each `$MINOR` version (i.e 3.1, 3.2). Each `$PATCH` release is a git tag off the `$MINOR`
branch. For example, 3.1.8 will be a git tag of 3.1.8.
When contributing code, be aware of the scope of your changes. If your change is backwards incompatible, raise your
change against the `master` branch. The master branch contains the next `$MAJOR` release. If the change is backwards
compatible raise it against the correct `$MINOR` branch.