6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2025-07-30 02:25:19 +00:00
Code Issues Projects Releases Wiki Activity

HowToReleaseLLVM: Add information about dot releases

Browse Source 
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
This commit is contained in:
Tom Stellard
2014-02-04 17:18:20 +00:00
parent 8f0354c973
commit efb6bb6863
1 changed files with 15 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
docs/HowToReleaseLLVM.rst
View File

@@ -22,12 +22,15 @@ create the binary packages, please refer to the :doc:`ReleaseProcess` instead.
Release Timeline Release Timeline
================ ================
LLVM is released on a time based schedule --- roughly every 6 months. We do LLVM is released on a time based schedule --- with major releases roughly
not normally have dot releases because of the nature of LLVM's incremental every 6 months. In between major releases there may be dot releases.
development philosophy. That said, the only thing preventing dot releases for The release manager will determine if and when to make a dot release based
critical bug fixes from happening is a lack of resources --- testers, on feedback from the community. Typically, dot releases should be made if
machines, time, etc. And, because of the high quality we desire for LLVM there are large number of bug-fixes in the stable branch or a critical bug
releases, we cannot allow for a truncated form of release qualification. 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: The release process is roughly as follows:
@@ -51,6 +54,10 @@ The release process is roughly as follows:
* Finally, release! * 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 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 #. During the remaining rounds of testing, only patches that fix critical
regressions may be applied. 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 Release Final Tasks
------------------- -------------------