[cfe-dev] [llvm-dev] RFC: Release process changes
John McCall via cfe-dev
cfe-dev at lists.llvm.org
Thu May 21 17:54:57 PDT 2020
On 21 May 2020, at 14:59, Tom Stellard via llvm-dev wrote:
> I would like to propose a few changes to the LLVM release process.
> current process is documented here:
> There are two parts to this proposal. The first is a list of
> which are things we are currently doing that aren't documented. The
> is a list of changes which would actually modify how releases are
> *** Proposed Clarifications ***
> ** Release manager is allowed to commit changes to the release branch
> code owner approval. However, the release manager is encouraged
> to consult
> with code owners or patch reviewers for non-trivial changes.
> It's not practical to get code owner approval every time. Either
> because there
> is no code owner or because the number of backports is too high (e.g.
> pre-rc1 / pre-rc2).
> This proposed clarification matches how releases are currently
If this is how things are currently managed, it’s hard to argue
but I do think that — independently — we should make a stronger
ensure that we have active code owners covering the entire codebase.
My sense is that the ownership problem is deepest in two specific parts
of the project: compiler-rt and LLVM itself. Do you agree?
> ** There is no official release criteria.
> We have time-based releases and when the release is 'ready' has been
> up to the discretion of the release manager. Changing the release
> criteria is out of the scope of this proposal, but I do think it would
> be good to have a discussion about this as a community, so I'm going
> start a separate thread to discuss this.
> *** Proposed Changes ***
> ** Create a time-based bug-fix release schedule. After each major
> release, make
> a new bug-fix release every 2 weeks for 12 weeks (6 releases
> ** Eliminate release candidates for bug-fix releases.
> The current unofficial bug-fix release schedule is:
> X.Y.1-rc1 (6 weeks after major release)
> X.Y.1-rc2 (10 weeks after major release)
> X.Y.1-final (12 weeks after major release)
> I think this change will improve the overall test coverage of the
> release branch.
> I don't think the branch itself or even the release candidates get the
> level of testing as the final releases. If we are consistently
> the release branch and putting out releases, I think this will make it
> and thus more likely that users will test out the release branch code.
> Additionally, with more frequent bug-fix release it removes the need
> to have
> release candidate releases. Every bug-fix release (up until the last
> would serve the same purpose as our current release candidates in that
> are intended to give users an easier way to test the code before the
> ** Create clear rules for what kind of backports are accepted during
> release phase.
> * Before RC1:Patches should be limited to bug fixes, important
> improvements, or completion of features that were started before the
> was created. As with all phases, release managers and code owners
> can reject
> patches that are deemed too invasive.
> * Before RC2: Patches should be limited to bug fixes or backend
> improvements that are determined to be very safe.
> * Before RC3/Final: Major Release* Patches should be limited to
> bugs or regressions.
> * Bug fix releases: Patches should be limited to bug fixes or very
> and critical performance improvements. Patches must maintain both
> API and
> ABI compatibility with the previous major release.
> * Final bug fix release: Patches should be limited to critical bug
> fixes only.
> What does everyone thing about these changes?
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
More information about the cfe-dev