VERSIONING.rst 1.7 KB

12345678910111213141516171819202122232425262728293031323334353637383940
  1. *****************
  2. Versioning Policy
  3. *****************
  4. We use a three-part X.Y.Z (Major.Minor.Patch) versioning definition, as follows:
  5. * **X (Major)** version changes are significant and expected to break backwards compatibility.
  6. * **Y (Minor)** version changes are moderate changes. These include:
  7. * Significant non-breaking feature additions.
  8. * Possible backwards-incompatible changes. These changes will be noted and explained in detail in the release notes.
  9. * **Z (Patch)** version changes are small changes. These changes will not break backwards compatibility.
  10. * Z releases will also include warning of upcoming breaking changes, whenever possible.
  11. Beta releases
  12. =============
  13. Versions with a zero major version (0.Y.Z) are considered to be beta
  14. releases. In beta releases, a Y-change may involve significant API changes.
  15. Branch stability
  16. ================
  17. Untagged branches (such as main) are not subject to any API or ABI
  18. stability policy; APIs may change at any time.
  19. What this means for you
  20. =======================
  21. We recommend running the most recent version. Here are our suggestions for managing updates:
  22. * Beta releases should be considered to be under flux. While we will try to minimize churn, expect that
  23. you'll need to make some changes to move to the 1.0.0 release.
  24. * X changes will require some effort to incorporate.
  25. * Y changes will not require significant effort to incorporate.
  26. * If you have good unit and integration tests, these changes are generally safe to pick up automatically.
  27. * Z changes will not require any changes to your code. Z changes are intended to be picked up automatically.
  28. * Good unit and integration tests are always recommended.