misc: Updated CONTRIBUTING.md to discuss releases and hotfixes

A new section in CONTRIBUTING.md has been added to discuss the
proceedure for how releases are carried out, as well as hotfixes.

Jira: https://gem5.atlassian.net/browse/GEM5-297
Change-Id: I49e7d6e41e8a6d5387c839eb26263e86dd52c294
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24843
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 2a24f0571cbc4e19b1ca788d1e9bd05c6c0fb78b..08619cb317fe66aa5fe7e527fad4e9342d2b074d 100644 (file)
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -481,3 +481,65 @@ contributors and reviewers to follow.
    intervention by the PMC are undesirable. Attempts should be made to resolve
    disagreements via respectful and polite discourse before being escalated to
    this level.
    intervention by the PMC are undesirable. Attempts should be made to resolve
    disagreements via respectful and polite discourse before being escalated to
    this level.

+
+Releases
+========
+
+gem5 releases occur 3 times per year. The procedure for releasing gem5 is as
+follows:
+
+1. Developers will be notified, via the gem5-dev mailing list, that a new
+release of gem5 will occur. This should be no sooner than 2 weeks prior to the
+expected release date. This gives time for developers to ensure their changes
+for the next release are submitted to the develop branch.
+2. When a release is ready, a new staging branch shall be created by a project
+maintainer, from develop, with the name "release-staging-{VERSION}".
+The gem5-dev mailing list will be notified that, unless justifiable objections
+are made, the staging branch will be merged into the master branch within the
+next week, thus marking the new release.
+3. The staging branch will have the full suite of gem5 tests run on it to
+ensure all tests pass and the to-be-released code is in a decent state.
+4. If reasonable concerns about the state of the staging branch are made by
+members of the gem5 community, then time shall be given for project
+contributors to rectify these concerns on the develop branch. After these
+changes have been incorporated, the develop branch will be re-merged into the
+staging branch. The staging branch will be re-evaluated via the tests, and the
+gem5 community informed of the changes with additional time given for more
+feedback on the new release.
+5. Once signed off by members of the PMC the staging branch shall be merged
+into the master branch, and the staging branch deleted.
+6. The master branch shall be tagged with the correct version number for that
+release. gem5 conforms to a "v{YY}.{MAJOR}.{MINOR}.{HOTFIX}" versioning system.
+E.g., the first major release of 2022 will be "v22.0.0.0", followed by
+"v22.1.0.0". All the releases (with the exemption hotfixes) are considered
+major releases. For the meantime, there are no minor releases though we keep
+the minor release numbers in case this policy changes in the future.
+7. The gem5-dev and gem5-user mailing lists shall be notified of the new gem5
+release.
+
+Hotfixes
+--------
+
+There may be circumstances in which a change to gem5 is deemed critical and
+cannot wait for an official release (e.g., a high-priority bug fix). In these
+circumstances a hotfix shall be made.
+
+First, if a developer suspects a hotfix may be necessary then the issue
+should be discussed on the gem5-dev mailing list. The community will decide
+whether the issue is worthy of a hotfix, and the final decision should be
+made by members of the PMC if there is no consensus. Assuming the hotfix is
+permitted, the following steps will be taken:
+
+1. A new branch with the prefix "hotfix-" will be created from the master
+branch. Only gem5 maintainers can create branches. If a non-maintainer requires
+the creation of a hotfix branch then they should contact a gem5 maintainer.
+2. The change shall be submitted to the hotfix branch via gerrit. Full review,
+as with any other change, will be required.
+3. Once fully submitted, the hotfix branch shall be merged into both the
+develop and the master branch by a gem5 maintainer.
+4. The master branch will be tagged with the new version number; the same as
+the last but with an incremented hotfix number (e.g., "v20.2.0.0" would
+transition to "v20.2.0.1").
+4. The hotfix branch will then be deleted.
+5. The gem5-dev and the gem5-user mailing lists shall be notified of this
+hotfix.