llvm dev - Jun 2016 - [3.9 Release] Release plan and call for testers

Hello everyone,

It's time to start planning for the 3.9 release.

Please let me know if you'd like to help providing binaries and
testing for your favourite platform.

I propose the following schedule:

- 18 July: Create the release branch; build and test RC1 soon thereafter.

- 1 August: Tag, build and test RC2. Any unfinished features need to
be turned off by now. As we get closer to the release, the bar for
merging patches rises.

- 22 August: Tag 3.9.0-final. The release ships when binaries are ready.


Also, I have three more questions for the community:

1) Right after the branch, the version number of the trunk will be
incremented. I assume this means bumping the major version number,
taking us to 4.0? IIUC, that's what happened after 1.9 and 2.9.

2) Following up on the May thread about the release process [1], I'd
like to make the schedule we've followed for the last few years more
official by posting somewhere on the web page that we're committed to
shipping two major releases per year: one in early March (branching
mid-January), and one early September (branching mid-July), usually
with one (or sometimes two) "dot" releases in between.

3) Another follow-up from that thread: it's usually the same people
who test the releases for their platform. Rather than asking everyone
each time, I'd like to make a list of who's responsible for each
platform and put that on the web page. Testers can still sign-up or
resign as they like, of course. Would you testers be OK with this?

Let me know what you think.

Cheers,
Hans


 [1]. http://lists.llvm.org/pipermail/llvm-dev/2016-May/099541.html

On 10 Jun 2016, at 22:38, Hans Wennborg via cfe-dev <cfe-dev at
lists.llvm.org> wrote:
> It's time to start planning for the 3.9 release.
> 
> Please let me know if you'd like to help providing binaries and
> testing for your favourite platform.
As usual, I volunteer for providing FreeBSD binaries and testing.


> I propose the following schedule:
> 
> - 18 July: Create the release branch; build and test RC1 soon thereafter.
> 
> - 1 August: Tag, build and test RC2. Any unfinished features need to
> be turned off by now. As we get closer to the release, the bar for
> merging patches rises.
> 
> - 22 August: Tag 3.9.0-final. The release ships when binaries are ready.
I would put three weeks between RC1 and RC2, to allow more last-minute
bugs to be fixed, and two weeks between RC2 and final, but it is always
little arbitrary.

> Also, I have three more questions for the community:
> 
> 1) Right after the branch, the version number of the trunk will be
> incremented. I assume this means bumping the major version number,
> taking us to 4.0? IIUC, that's what happened after 1.9 and 2.9.
4.0.  Since gcc is already at 7.0, we need to catch up! ;-)

> 2) Following up on the May thread about the release process [1], I'd
> like to make the schedule we've followed for the last few years more
> official by posting somewhere on the web page that we're committed to
> shipping two major releases per year: one in early March (branching
> mid-January), and one early September (branching mid-July), usually
> with one (or sometimes two) "dot" releases in between.
Having predictable release schedules is nice.  If everybody knows the
tree should be in fairly good shape at the point of branching, any heavy
refactoring can be postponed until after such branching (or preferably,
until after the actual release).

> 3) Another follow-up from that thread: it's usually the same people
> who test the releases for their platform. Rather than asking everyone
> each time, I'd like to make a list of who's responsible for each
> platform and put that on the web page. Testers can still sign-up or
> resign as they like, of course. Would you testers be OK with this?
You can put me up for the FreeBSD platform, obviously.

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160612/e16beefe/attachment.sig>

On Fri, Jun 10, 2016 at 01:38:22PM -0700, Hans Wennborg via llvm-dev
wrote:
> Hello everyone,
> 
> It's time to start planning for the 3.9 release.
> 
> Please let me know if you'd like to help providing binaries and
> testing for your favourite platform.
> 
> I propose the following schedule:
> 
> - 18 July: Create the release branch; build and test RC1 soon thereafter.
> 
> - 1 August: Tag, build and test RC2. Any unfinished features need to
> be turned off by now. As we get closer to the release, the bar for
> merging patches rises.
> 
> - 22 August: Tag 3.9.0-final. The release ships when binaries are ready.
> 
> 
> Also, I have three more questions for the community:
> 
> 1) Right after the branch, the version number of the trunk will be
> incremented. I assume this means bumping the major version number,
> taking us to 4.0? IIUC, that's what happened after 1.9 and 2.9.
> 
The 4.1 release gives us the opportunity to drop support for 3.x
bitcode formats, so  I don't think we should move to 4.x until we have
older bitcode features that we really want to drop.  There should
probably be a separate discussion thread about this.

-Tom



> 2) Following up on the May thread about the release process [1], I'd
> like to make the schedule we've followed for the last few years more
> official by posting somewhere on the web page that we're committed to
> shipping two major releases per year: one in early March (branching
> mid-January), and one early September (branching mid-July), usually
> with one (or sometimes two) "dot" releases in between.
> 
> 3) Another follow-up from that thread: it's usually the same people
> who test the releases for their platform. Rather than asking everyone
> each time, I'd like to make a list of who's responsible for each
> platform and put that on the web page. Testers can still sign-up or
> resign as they like, of course. Would you testers be OK with this?
> 
This is a great idea.

-Tom
> Let me know what you think.
> 
> Cheers,
> Hans
> 
> 
>  [1]. http://lists.llvm.org/pipermail/llvm-dev/2016-May/099541.html
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

> The 4.1 release gives us the opportunity to drop support for 3.x
> bitcode formats, so  I don't think we should move to 4.x until we have
> older bitcode features that we really want to drop.  There should
> probably be a separate discussion thread about this.
It give the opportunity, not the obligation. Given that I think it is
an independent issue and would suggest we just keep the revisions
simple and switch trunk to 4.0.

Cheers,
Rafael

On 12 June 2016 at 13:27, Dimitry Andric via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>> 1) Right after the branch, the version number of the trunk will be
>> incremented. I assume this means bumping the major version number,
>> taking us to 4.0? IIUC, that's what happened after 1.9 and 2.9.
>
> 4.0.  Since gcc is already at 7.0, we need to catch up! ;-)
Or, we can do like ARM and go from 3 straight to 7! :)

>> 2) Following up on the May thread about the release process [1],
I'd
>> like to make the schedule we've followed for the last few years
more
>> official by posting somewhere on the web page that we're committed
to
>> shipping two major releases per year: one in early March (branching
>> mid-January), and one early September (branching mid-July), usually
>> with one (or sometimes two) "dot" releases in between.
>
> Having predictable release schedules is nice.  If everybody knows the
> tree should be in fairly good shape at the point of branching, any heavy
> refactoring can be postponed until after such branching (or preferably,
> until after the actual release).
Yup, +1 for a webpage with all this, in addition to the existing
snippet on the homepage.

>> 3) Another follow-up from that thread: it's usually the same people
>> who test the releases for their platform. Rather than asking everyone
>> each time, I'd like to make a list of who's responsible for
each
>> platform and put that on the web page. Testers can still sign-up or
>> resign as they like, of course. Would you testers be OK with this?
>
> You can put me up for the FreeBSD platform, obviously.
And me for ARM and AArch64.

cheers,
--renato

On Saturday, June 11, 2016 04:38 AM, Hans Wennborg via llvm-dev
wrote:
> Hello everyone,
>
> It's time to start planning for the 3.9 release.
>
> Please let me know if you'd like to help providing binaries and
> testing for your favourite platform.
Yep, happy to do Ubuntu x86_64.
> 3) Another follow-up from that thread: it's usually the same people
> who test the releases for their platform. Rather than asking everyone
> each time, I'd like to make a list of who's responsible for each
> platform and put that on the web page. Testers can still sign-up or
> resign as they like, of course. Would you testers be OK with this?
No problem.

Ben

On Fri, Jun 10, 2016 at 1:38 PM, Hans Wennborg <hans at chromium.org>
wrote:
> 2) Following up on the May thread about the release process [1], I'd
> like to make the schedule we've followed for the last few years more
> official by posting somewhere on the web page that we're committed to
> shipping two major releases per year: one in early March (branching
> mid-January), and one early September (branching mid-July), usually
> with one (or sometimes two) "dot" releases in between.
>
> 3) Another follow-up from that thread: it's usually the same people
> who test the releases for their platform. Rather than asking everyone
> each time, I'd like to make a list of who's responsible for each
> platform and put that on the web page. Testers can still sign-up or
> resign as they like, of course. Would you testers be OK with this?
I've sent out a patch to update the docs for this:
http://reviews.llvm.org/D21880

Please take a look.