|
2 | 2 | Versioning Policy
|
3 | 3 | *****************
|
4 | 4 |
|
5 |
| -We will use a three-part X.Y.Z (Major.Minor.Patch) versioning definition with the following meanings. |
| 5 | +We use a three-part X.Y.Z (Major.Minor.Patch) versioning definition, as follows: |
6 | 6 |
|
7 |
| -* X (Major) version changes cover changes to the code-base that are expected to break backwards compatibility. |
8 |
| -* 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. |
9 |
| -* Z (Patch) version changes cover small changes. They will not break backwards compatibility. |
| 7 | +* **X (Major)** version changes are significant and expected to break backwards compatibility. |
| 8 | +* **Y (Minor)** version changes are moderate changes. These include: |
| 9 | + |
| 10 | + * Significant non-breaking feature additions. |
| 11 | + * Any change to the version of a dependency. |
| 12 | + * Possible backwards-incompatible changes. These changes will be noted and explained in detail in the release notes. |
| 13 | + |
| 14 | +* **Z (Patch)** version changes are small changes. These changes will not break backwards compatibility. |
| 15 | + |
| 16 | + * Z releases will also include warning of upcoming breaking changes, whenever possible. |
10 | 17 |
|
11 | 18 | What this means for you
|
12 | 19 | =======================
|
13 | 20 |
|
14 |
| -We definitely recommend always running on the most recent version of our code. This is how we recommend doing so. |
| 21 | +We recommend running the most recent version. Here are our suggestions for managing updates: |
| 22 | + |
| 23 | +* X changes will require some effort to incorporate. |
| 24 | +* Y changes will not require significant effort to incorporate. |
| 25 | + |
| 26 | + * If you have good unit and integration tests, these changes are generally safe to pick up automatically. |
| 27 | + |
| 28 | +* Z changes will not require any changes to your code. Z changes are intended to be picked up automatically. |
15 | 29 |
|
16 |
| -* X changes will likely require dedicated time and work to incorporate into your code-base. |
17 |
| -* 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. |
18 |
| -* 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.) |
| 30 | + * Good unit and integration tests are always recommended. |
19 | 31 |
|
0 commit comments