From 7f56e81331d403e8377c1178699aca2dc2591383 Mon Sep 17 00:00:00 2001 From: Vaclav Petras Date: Tue, 23 Apr 2024 16:29:05 -0400 Subject: [PATCH 1/5] Create release_policy.md --- doc/development/rfc/release_policy.md | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 doc/development/rfc/release_policy.md diff --git a/doc/development/rfc/release_policy.md b/doc/development/rfc/release_policy.md new file mode 100644 index 00000000000..cc3441e7517 --- /dev/null +++ b/doc/development/rfc/release_policy.md @@ -0,0 +1,2 @@ +# RFC: Release Policy + From 981cf1c33ed84cc9fb0beb783831d063b08e23f9 Mon Sep 17 00:00:00 2001 From: Vaclav Petras Date: Wed, 24 Apr 2024 23:38:36 -0400 Subject: [PATCH 2/5] Initial text --- doc/development/rfc/release_policy.md | 31 +++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/doc/development/rfc/release_policy.md b/doc/development/rfc/release_policy.md index cc3441e7517..3cd7b19e61c 100644 --- a/doc/development/rfc/release_policy.md +++ b/doc/development/rfc/release_policy.md @@ -1,2 +1,33 @@ # RFC: Release Policy +Author: Vaclav Petras + +Status: Draft + +## Goal + +The goal of this document is to define when releases should be created and what types releases should be created. + +## Frequency + +One major or minor release should be released once a year. +The may be multiple micro releases per year. + +## Maitanance + +We have only one actively updated, maintained, and supported release series. + +Once a new major or minor version is released, the old release series goes to +a low maintenance mode and no further released are planned. +Low maintanance series are no longer actively updated, but can be updated on demand, +i.e., if you submit a patch to fix a bug, we will likely accept it and +create a new release when there is enough changes accumulated +or support you in creating the release as a temporary release manager. + +## Additional Types of Releases + +For some platfroms we have daily builds of development version from main. + +## Relation to Other Documents + +* Release procedure covers branching and creation of pre-releases. From e255e4a73ffd85e706ecfad2f7bdda30c7fd7d5f Mon Sep 17 00:00:00 2001 From: Vaclav Petras Date: Fri, 26 Apr 2024 15:55:05 -0400 Subject: [PATCH 3/5] Draft hitting the major points --- doc/development/rfc/release_policy.md | 109 +++++++++++++++++++++++--- 1 file changed, 97 insertions(+), 12 deletions(-) diff --git a/doc/development/rfc/release_policy.md b/doc/development/rfc/release_policy.md index 3cd7b19e61c..293d9a21469 100644 --- a/doc/development/rfc/release_policy.md +++ b/doc/development/rfc/release_policy.md @@ -6,28 +6,113 @@ Status: Draft ## Goal -The goal of this document is to define when releases should be created and what types releases should be created. +The goal of this document is to define when releases should be created +and what types releases should be created. -## Frequency +## Summary One major or minor release should be released once a year. -The may be multiple micro releases per year. +This becomes the only actively maintained release series +which is subsequently updated by micro releases as needed. +Individual contributors can step up to maintain an older release series. + +## Types of Releases + +We recognize major, minor, micro releases and additional helper versions +each with its unique purpose. + +The releases follow rules and numbering specified in the Version Numbering RFC. + +### Major and Minor + +Both major and minor releases bring new features to the users +and in that regard should receive similar attention by the contributors. +However, they differ in how backwards compatibility is handled. + +While major release brings features just like a minor release, +it may also bring changes breaking backwards compatibility +such as breaking API changes. Additionally, contributors may decide +to include certain feature into a major release rather than a minor release +if the feature has a potential to negatively impact some users or use cases. +A major release may include a particularly important feature or a set of features, +but that's not required. The purpose of a major release is to bring changes +which cannot be included into a minor release such as A or some extensive code rewrites. +It may or may not be used to bring revolutionary changes or highlight specific features. + +Minor release may bring any new features, small or big, as long as backwards +compatibility is kept, e.g., an automated procedure relying on public API should +still work. The purpose of a minor release is to bring features to the users +as soon as possible with software stability and compatibility and without +a need to wait for a major release. + +Both major and minor releases may include bugfixes which may or may not be +already included in a micro release of the previous major or minor release. + +A special effort is put into keeping backwards compatibility. +While this is a requirement for minor version, the community makes extra effort +even for major release to maximize backwards compatibility so that users can +conveniently transition to new versions. + +### Micro + +Micro releases should contain only bugfixes. +Their purpose is to fix issues with a particular major or minor release. +Providing both stability and fixes to the users. -## Maitanance +A minor release should be considered instead of a micro release when +a bugfix is large, a bugfix has unclear side-effects, or it is not clear +if it is bugfix or a feature given that, in practice, the line between +a bugfix and a feature is not completely clear. -We have only one actively updated, maintained, and supported release series. +### Pre-releases and Daily Builds + +There can be zero or more release candidates, i.e., pre-releases, +for each major, minor, or micro release. The specifics are determined +by the Release Procedure RFC. + +There can be daily or per-commit frequent builds of +which can serve as preview versions or version for testing. +Other frequencies are permissable but not recommended. + +### Post-releases and Build Versions + +There can be subsequent builds of a specific release +if build or packaging process failed and needs fixing. +However, there shouldn't be any post-releases, i.e., +if there is a change in the code base to fix a flaw in a release, +a new micro release should be created. + +## Frequency + +One major or minor release should be released at least once a year. +More then one major or minor release may be released +if the contributors consider that necessary or advantageous. +There is no requirement for frequency of major releases, but +the practice and rhythm so far was to release major version +before the minor version number reaches value ten which translates +to a major release every five to ten years. + +There can be zero or more micro releases per year for different major or minor +release based on the needs of the community practically driven by the number +of fixes accumulated for a particular release. + +## Maintenance + +We have one actively updated, maintained, and supported release series +which is started by a release of a new major or minor version. +We release micro versions in this series throughout the year as needed. Once a new major or minor version is released, the old release series goes to -a low maintenance mode and no further released are planned. -Low maintanance series are no longer actively updated, but can be updated on demand, -i.e., if you submit a patch to fix a bug, we will likely accept it and +a low maintenance mode and no further releases are planned. +However, any low maintenance series can be updated on demand. +If you submit a patch to fix a bug, we will likely accept it and create a new release when there is enough changes accumulated or support you in creating the release as a temporary release manager. - -## Additional Types of Releases - -For some platfroms we have daily builds of development version from main. +Security fixes will be given special consideration in light of how wide +the usage of a particular release series is. ## Relation to Other Documents * Release procedure covers branching and creation of pre-releases. +* Version number covers how major, minor, micro releases are numbered + and what changes can be included in a release. From e4439a43974de4692963793db48bbeaff2debd48 Mon Sep 17 00:00:00 2001 From: Vaclav Petras Date: Tue, 30 Apr 2024 09:20:07 -0400 Subject: [PATCH 4/5] Better wording and defs --- doc/development/rfc/release_policy.md | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/doc/development/rfc/release_policy.md b/doc/development/rfc/release_policy.md index 293d9a21469..ec446c908d3 100644 --- a/doc/development/rfc/release_policy.md +++ b/doc/development/rfc/release_policy.md @@ -11,7 +11,7 @@ and what types releases should be created. ## Summary -One major or minor release should be released once a year. +One major or minor release should be released per year. This becomes the only actively maintained release series which is subsequently updated by micro releases as needed. Individual contributors can step up to maintain an older release series. @@ -34,15 +34,17 @@ it may also bring changes breaking backwards compatibility such as breaking API changes. Additionally, contributors may decide to include certain feature into a major release rather than a minor release if the feature has a potential to negatively impact some users or use cases. -A major release may include a particularly important feature or a set of features, -but that's not required. The purpose of a major release is to bring changes -which cannot be included into a minor release such as A or some extensive code rewrites. -It may or may not be used to bring revolutionary changes or highlight specific features. +A major release may include a particularly important feature or a set of +features, but that's not required. The purpose of a major release is to bring +changes which cannot be included into a minor release such as +backwards-incompatible changes in API or unusually large code rewrites. +It may or may not be used to bring revolutionary changes or highlight specific +features. Minor release may bring any new features, small or big, as long as backwards -compatibility is kept, e.g., an automated procedure relying on public API should -still work. The purpose of a minor release is to bring features to the users -as soon as possible with software stability and compatibility and without +compatibility is kept, e.g., an automated procedure relying on public API +still works. The purpose of a minor release is to bring features to the users +as soon as possible with software stability and compatibility, but without a need to wait for a major release. Both major and minor releases may include bugfixes which may or may not be @@ -51,18 +53,19 @@ already included in a micro release of the previous major or minor release. A special effort is put into keeping backwards compatibility. While this is a requirement for minor version, the community makes extra effort even for major release to maximize backwards compatibility so that users can -conveniently transition to new versions. +conveniently transition to new versions. This is, however, not guaranteed and +it depends on many factors. ### Micro Micro releases should contain only bugfixes. Their purpose is to fix issues with a particular major or minor release. -Providing both stability and fixes to the users. +They provide software stability and fixes to the users. A minor release should be considered instead of a micro release when a bugfix is large, a bugfix has unclear side-effects, or it is not clear -if it is bugfix or a feature given that, in practice, the line between -a bugfix and a feature is not completely clear. +whether a particular change is bugfix or a feature given that, in practice, +the line between a bugfix and a feature is not completely clear. ### Pre-releases and Daily Builds From 3fbf6b4a1d50ea462cda984982ffb474b939c1e4 Mon Sep 17 00:00:00 2001 From: Vaclav Petras Date: Fri, 10 May 2024 12:28:16 -0400 Subject: [PATCH 5/5] Apply suggestions from code review Co-authored-by: Veronica Andreo --- doc/development/rfc/release_policy.md | 37 ++++++++++++++------------- 1 file changed, 19 insertions(+), 18 deletions(-) diff --git a/doc/development/rfc/release_policy.md b/doc/development/rfc/release_policy.md index ec446c908d3..3a5e7e51d74 100644 --- a/doc/development/rfc/release_policy.md +++ b/doc/development/rfc/release_policy.md @@ -7,7 +7,7 @@ Status: Draft ## Goal The goal of this document is to define when releases should be created -and what types releases should be created. +and what types of releases should be created. ## Summary @@ -51,8 +51,8 @@ Both major and minor releases may include bugfixes which may or may not be already included in a micro release of the previous major or minor release. A special effort is put into keeping backwards compatibility. -While this is a requirement for minor version, the community makes extra effort -even for major release to maximize backwards compatibility so that users can +While this is a requirement for minor versions, the community makes extra effort +even for major releases to maximize backwards compatibility so that users can conveniently transition to new versions. This is, however, not guaranteed and it depends on many factors. @@ -73,9 +73,9 @@ There can be zero or more release candidates, i.e., pre-releases, for each major, minor, or micro release. The specifics are determined by the Release Procedure RFC. -There can be daily or per-commit frequent builds of -which can serve as preview versions or version for testing. -Other frequencies are permissable but not recommended. +There can be daily or per-commit frequent builds +which can serve as preview versions or versions for testing. +Other frequencies are permitted but not recommended. ### Post-releases and Build Versions @@ -88,29 +88,30 @@ a new micro release should be created. ## Frequency One major or minor release should be released at least once a year. -More then one major or minor release may be released +More than one major or minor release may be released if the contributors consider that necessary or advantageous. -There is no requirement for frequency of major releases, but -the practice and rhythm so far was to release major version -before the minor version number reaches value ten which translates +There is no frequency requirement for major releases, but +the practice and rhythm so far was to release a new major version +before the minor version number reaches the value ten which translates to a major release every five to ten years. There can be zero or more micro releases per year for different major or minor -release based on the needs of the community practically driven by the number -of fixes accumulated for a particular release. +releases based on the needs of the community and practically driven by the number +of fixes accumulated. ## Maintenance -We have one actively updated, maintained, and supported release series +At any time there is one actively updated, maintained, and supported release series which is started by a release of a new major or minor version. -We release micro versions in this series throughout the year as needed. +There are micro versions releases in this series throughout the year as needed. Once a new major or minor version is released, the old release series goes to a low maintenance mode and no further releases are planned. However, any low maintenance series can be updated on demand. -If you submit a patch to fix a bug, we will likely accept it and -create a new release when there is enough changes accumulated -or support you in creating the release as a temporary release manager. +If a contributor submits a patch to fix a bug, it will be likely accepted and +a new release will be created when there are enough changes accumulated. +Alternatively the contributor might receive support in creating the release as +a temporary release manager. Security fixes will be given special consideration in light of how wide the usage of a particular release series is. @@ -118,4 +119,4 @@ the usage of a particular release series is. * Release procedure covers branching and creation of pre-releases. * Version number covers how major, minor, micro releases are numbered - and what changes can be included in a release. + and what types of changes can be included in a release.