release-process.rst (2336B)
1 Release Process 2 =============== 3 4 Because of h2's place at the bottom of the dependency tree, it is 5 extremely important that the project maintains a diligent release schedule. 6 This document outlines our process for managing releases. 7 8 Versioning 9 ---------- 10 11 h2 follows `semantic versioning`_ of its public API when it comes to 12 numbering releases. The public API of h2 is strictly limited to the 13 entities listed in the :doc:`api` documentation: anything not mentioned in that 14 document is not considered part of the public API and is not covered by the 15 versioning guarantees given by semantic versioning. 16 17 Maintenance 18 ----------- 19 20 h2 has the notion of a "release series", given by a major and minor 21 version number: for example, there is the 2.1 release series. When each minor 22 release is made and a release series is born, a branch is made off the release 23 tag: for example, for the 2.1 release series, the 2.1.X branch. 24 25 All changes merged into the master branch will be evaluated for whether they 26 can be considered 'bugfixes' only (that is, they do not affect the public API). 27 If they can, they will also be cherry-picked back to all active maintenance 28 branches that require the bugfix. If the bugfix is not necessary, because the 29 branch in question is unaffected by that bug, the bugfix will not be 30 backported. 31 32 Supported Release Series' 33 ------------------------- 34 35 The developers of h2 commit to supporting the following release series: 36 37 - The most recent, as identified by the first two numbers in the highest 38 version currently released. 39 - The immediately prior release series. 40 41 The only exception to this policy is that no release series earlier than the 42 2.1 series will be supported. In this context, "supported" means that they will 43 continue to receive bugfix releases. 44 45 For releases other than the ones identified above, no support is guaranteed. 46 The developers may *choose* to support such a release series, but they do not 47 promise to. 48 49 The exception here is for security vulnerabilities. If a security vulnerability 50 is identified in an out-of-support release series, the developers will do their 51 best to patch it and issue an emergency release. For more information, see 52 `our security documentation`_. 53 54 55 .. _semantic versioning: http://semver.org/ 56 .. _our security documentation: http://python-hyper.org/en/latest/security.html