From 1db7ecb4ce46e4ea525e6564032b4486c72c1c41 Mon Sep 17 00:00:00 2001 From: "Bobby R. Bruce" Date: Mon, 27 Jan 2020 18:43:32 -0800 Subject: [PATCH] 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 Reviewed-by: Jason Lowe-Power Maintainer: Bobby R. Bruce Tested-by: kokoro --- CONTRIBUTING.md | 62 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 62 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 2a24f0571..08619cb31 100644 --- 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. + +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. -- 2.30.2