Skip to content

Statement of our versioning policy and philosophy #46

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Aug 10, 2018
Merged

Statement of our versioning policy and philosophy #46

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
00e8bce
Statement of our versioning policy and philosophy
SalusaSecondus Aug 10, 2018
236149a
Update VERSIONING.rst
mattsb42-aws Aug 10, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 19 additions & 0 deletions VERSIONING.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
*****************
Versioning Policy
*****************

We will use a three-part X.Y.Z (Major.Minor.Patch) versioning definition with the following meanings.

* X (Major) version changes cover changes to the code-base that are expected to break backwards compatibility.
* Y (Minor) version changes cover moderate changes. These include significant (non-breaking) feature additions and might contain changes which break backwards compatability. If there are breaking changes, they will be explicitly stated in the release notes.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

compatibility not compatability

* Z (Patch) version changes cover small changes. They will not break backwards compatibility.

What this means for you
=======================

We definitely recommend always running on the most recent version of our code. This is how we recommend doing so.

* X changes will likely require dedicated time and work to incorporate into your code-base.
* Y changes are unlikely to require significant (or any) work to incorporate. If you have good unit and integration tests, they can likely be picked up in an automated manner.
* Z changes should not require any changes to your code and can be picked up in an automated manner. (Good unit and integration tests are always recommended.)