[llvm-dev] 4.0.1 Release Schedule + Need feedback for improving stable releases

[Tom Stellard via llvm-dev]

Hi,

I would like to start a discussion about improvements to the
stable release process, but first, here is a proposed schedule
for the 4.0.1 release.

May 1, 2017 -rc1
May 22, 2017 Deadline for submitting merge request
May 29, 2017 Deadline for merging changes.
June 3, 2017 -rc2
June 10, 2017 Final Release

This is slightly different from previous stable releases in that
we are doing an early -rc1 release.  This matches what we do for
major releases, and I think it will help us get more feedback from
testers sooner.

There is now a script in utils/release, called merge-request.sh, which
you can use to submit merge requests to bugzilla.  It's recommend
that you use this script in order to give us consistent bugzilla entries.
However, you can still file bugzilla requests manually if for some
reason you are unable to use the script.

If you file bugs manually, make sure you mark it as a blocker for
the release metabug: 32061 and add a link the commit on phabricator
in the url field: e.g http://reviews.llvm.org/rL12345

Description for the bug should be in the form of:

Merge r123456 into the 4.0 branch : <80 character commit message summary>


* Stable Release Improvements *

I would like to start an informal discussion about stable release
improvements.  My goals for this discussion are to find ways to
get more community members/organizations using the official stable
releases, and also to help simplify the release process for users,
testers, and release managers.

* Ideas:

1. Longer support for stable release. We currently have 2 major and 2
stable releases per year.  Each major release is effectively supported
for only 3 months, because after the x.y.1 release , we move on to the
next major version.  Our current release schedule is approximately:

March: x.y.0
June x.y.1
Sept: (x+1).y.0 
Dec: (x+1).y.1

One idea is to move to 6 releases per year and have an additional
x.y.2 release after (x+1).y.0, but before (x+1).y.0.  This would
mean that stable releases are supported for ~ 8 months. So something
like:

Jan:   (x-1).y.1 
March: x.y.0
May:   (x-1).y.2
July:  x.y.1
Sept:  (x+1).y.0
Nov:   x.y.2 

What do people think about this or other alternative release schedules?
Would this kind of extended support make stable releases more
attractive to users/organizations that use LLVM.

My main concern with adding an extra release is placing an extra
burden on release testers.  For release testers is doing two
more releases per year practical?



2. Automated release testing.  This is connected to the previous
idea.  Can we automate the release testing?  It would be great if
we had some release tester bots that would test the release
candidates and upload the binaries.  It seems like this should
be doable within the current buildbot infrastructure.  Is the
only thing that keeps us from doing this, lack of dedicated test
hardware?


3. Automated merge requests.  I would like to come up with a way
that we can tag commit messages so that a post-commit hook would
be able to automatically create merge requests in bugzilla.
There are a few ways I can think of to tag the messages, but I'm
just going to propose that adding the following line:

STABLE: 4.0

To commit messages would make it a candidate for an automated
merge request.  Any thoughts?


4. Other Ideas.  Does anyone else have other ideas for improving
stable releases?


Thanks,
Tom