From efb6bb68637230b666b88c915be6ffa1426afab6 Mon Sep 17 00:00:00 2001 From: Tom Stellard Date: Tue, 4 Feb 2014 17:18:20 +0000 Subject: HowToReleaseLLVM: Add information about dot releases Based on the following discussion: http://llvm.1065342.n5.nabble.com/LLVM-3-4-stable-releases-td65005.html git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200772 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/HowToReleaseLLVM.rst | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) (limited to 'docs/HowToReleaseLLVM.rst') diff --git a/docs/HowToReleaseLLVM.rst b/docs/HowToReleaseLLVM.rst index 6194fdfc86..f86c0ae613 100644 --- a/docs/HowToReleaseLLVM.rst +++ b/docs/HowToReleaseLLVM.rst @@ -22,12 +22,15 @@ create the binary packages, please refer to the :doc:`ReleaseProcess` instead. Release Timeline ================ -LLVM is released on a time based schedule --- roughly every 6 months. We do -not normally have dot releases because of the nature of LLVM's incremental -development philosophy. That said, the only thing preventing dot releases for -critical bug fixes from happening is a lack of resources --- testers, -machines, time, etc. And, because of the high quality we desire for LLVM -releases, we cannot allow for a truncated form of release qualification. +LLVM is released on a time based schedule --- with major releases roughly +every 6 months. In between major releases there may be dot releases. +The release manager will determine if and when to make a dot release based +on feedback from the community. Typically, dot releases should be made if +there are large number of bug-fixes in the stable branch or a critical bug +has been discovered that affects a large number of users. + +Unless otherwise stated, dot releases will follow the same procedure as +major releases. The release process is roughly as follows: @@ -51,6 +54,10 @@ The release process is roughly as follows: * Finally, release! +The release process will be accelerated for dot releases. If the first round +of testing finds no critical bugs and no regressions since the last major release, +then additional rounds of testing will not be required. + Release Process =============== @@ -352,6 +359,8 @@ Below are the rules regarding patching the release branch: #. During the remaining rounds of testing, only patches that fix critical regressions may be applied. +#. For dot releases all patches must mantain both API and ABI compatibility with + the previous major release. Only bugfixes will be accepted. Release Final Tasks ------------------- -- cgit v1.2.3