Change release branch creation process to bump version to N.1.0. (#75743)

This will help distinguish release branch builds from development branch
builds, and is similar to GCC's version numbering policy.

Thus, the branch `releases/18.x` will start out numbered 18.1.0, instead
of 18.0.0.

Unchanged are other versioning policies:
- mainline will be numbered 18.0.0, 19.0.0, ...
- typical release branch releases will increment micro version, e.g.
18.1.1, 18.1.2, ....
- If an ABI break is required on the release branch, the minor version
will be incremented, e.g. to 18.2.0.

See the Discourse RFC:

https://discourse.llvm.org/t/rfc-name-the-first-release-from-a-branch-n-1-0-instead-of-n-0-0/75384
This commit is contained in:
James Y Knight 2023-12-22 17:35:26 -05:00 committed by GitHub
parent 0e039fc39e
commit 4532617ae4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -40,16 +40,16 @@ Release Approx. Date
=============================== =========================
*release branch: even releases* *4th Tue in January*
*release branch: odd releases* *4th Tue in July*
X.0.0-rc1 3 days after branch.
X.0.0-rc2 2 weeks after branch.
X.0.0-rc3 4 weeks after branch
**X.0.0-final** **6 weeks after branch**
**X.0.1** **8 weeks after branch**
**X.0.2** **10 weeks after branch**
**X.0.3** **12 weeks after branch**
**X.0.4** **14 weeks after branch**
**X.0.5** **16 weeks after branch**
**X.0.6 (if necessary)** **18 weeks after branch**
X.1.0-rc1 3 days after branch.
X.1.0-rc2 2 weeks after branch.
X.1.0-rc3 4 weeks after branch
**X.1.0-final** **6 weeks after branch**
**X.1.1** **8 weeks after branch**
**X.1.2** **10 weeks after branch**
**X.1.3** **12 weeks after branch**
**X.1.4** **14 weeks after branch**
**X.1.5** **16 weeks after branch**
**X.1.6 (if necessary)** **18 weeks after branch**
=============================== =========================
Release Process Summary
@ -77,7 +77,7 @@ Release Process Summary
* Announce bug fix release schedule to the LLVM community and update the website.
* Do bug-fix releases every two weeks until X.0.5 or X.0.6 (if necessary).
* Do bug-fix releases every two weeks until X.1.5 or X.1.6 (if necessary).
Release Process
===============
@ -123,6 +123,9 @@ Branch the Git trunk using the following procedure:
version bump. The branch's name is release/X.x where ``X`` is the major version
number and ``x`` is just the letter ``x``.
#. On the newly-created release branch, immediately bump the version
to X.1.0git (where ``X`` is the major version of the branch.)
#. All tags and branches need to be created in both the llvm/llvm-project and
llvm/llvm-test-suite repos.
@ -406,13 +409,13 @@ Announce the Release
^^^^^^^^^^^^^^^^^^^^
Create a new post in the `Announce Category <https://discourse.llvm.org/c/announce>`_
once all the release tasks are complete. For X.0.0 releases, make sure to include a
link to the release notes in the post. For X.0.1+ releases, generate a changelog
once all the release tasks are complete. For X.1.0 releases, make sure to include a
link to the release notes in the post. For X.1.1+ releases, generate a changelog
using this command and add it to the post.
::
$ git log --format="- %aN: [%s (%h)](https://github.com/llvm/llvm-project/commit/%H)" llvmorg-X.0.N-1..llvmorg-X.0.N
$ git log --format="- %aN: [%s (%h)](https://github.com/llvm/llvm-project/commit/%H)" llvmorg-X.1.N-1..llvmorg-X.1.N
Once the release has been announced add a link to the announcement on the llvm
homepage (from the llvm-www repo) in the "Release Emails" section.