[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

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! :wink:

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

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

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

I don’t think that this makes it simple for anyone. Existing packaging tools understand dot notation and know that 3.10 > 3.9, even if interpreting the dot as a decimal point would mean that it didn’t. Without this kind of special handling, they’d be very confused by 3.4.1, which isn’t even a valid number.

LLVM minor revisions break ABI and API compatibility and bugfix revisions don’t. There is an expectation that major revisions will break the bitcode format, so releasing a 4.0 version but saying ‘this one doesn’t actually break it’ will be confusing. Particularly if we then release a 5.0 that does, after a 4.5 that doesn’t.

That said, in general I’d prefer if we used semantic versioning and stopped releasing major versions with a bump of the minor version number.

David

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! :wink:

Or, we can do like ARM and go from 3 straight to 7! :slight_smile:

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

I don’t think that this makes it simple for anyone. Existing packaging tools understand dot notation and know that 3.10 > 3.9, even if interpreting the dot as a decimal point would mean that it didn’t. Without this kind of special handling, they’d be very confused by 3.4.1, which isn’t even a valid number.

Hi David,

This is indeed at odds with the rest of the open source community, but
it's what we've been doing for a long time... I don't particularly
like it myself, but I don't think it's evil.

LLVM minor revisions break ABI and API compatibility and bugfix revisions don’t. There is an expectation that major revisions will break the bitcode format, so releasing a 4.0 version but saying ‘this one doesn’t actually break it’ will be confusing. Particularly if we then release a 5.0 that does, after a 4.5 that doesn’t.

Well, the idea here is that in "3.9.0", "3.9" is the major "number"
and ".0" is the minor. I'm not saying it's a good scheme (because
tools already understand the other one), but in essence, we *do* break
all stuff between "majors", which means as much from 3.7 to 3.8 as it
does from 3.9 to 4.0.

That said, in general I’d prefer if we used semantic versioning and stopped releasing major versions with a bump of the minor version number.

I weekly support this, as it is my preferred scheme, and all OSS tools
already understand those *very* well indeed. But I wouldn't want to
enforce it for this July. :slight_smile:

Maybe we can think of 4.0 as the last of the "weird major release",
and plan well in advance to move to 5.0 when we're ready, not when the
clock ticked. But that could bring a whole lot of other things like
holding off features during code freeze, have multiple branches in Git
for experimental features, etc. which I'd *also* welcome, but all in
good time. Let's move to Git-only first.

cheers,
--renato

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

I don’t think that this makes it simple for anyone. Existing packaging tools understand dot notation and know that 3.10 > 3.9, even if interpreting the dot as a decimal point would mean that it didn’t. Without this kind of special handling, they’d be very confused by 3.4.1, which isn’t even a valid number.

Hi David,

This is indeed at odds with the rest of the open source community, but
it's what we've been doing for a long time... I don't particularly
like it myself, but I don't think it's evil.

LLVM minor revisions break ABI and API compatibility and bugfix revisions don’t. There is an expectation that major revisions will break the bitcode format, so releasing a 4.0 version but saying ‘this one doesn’t actually break it’ will be confusing. Particularly if we then release a 5.0 that does, after a 4.5 that doesn’t.

Well, the idea here is that in "3.9.0", "3.9" is the major "number"
and ".0" is the minor. I'm not saying it's a good scheme (because
tools already understand the other one), but in essence, we *do* break
all stuff between "majors", which means as much from 3.7 to 3.8 as it
does from 3.9 to 4.0.

That said, in general I’d prefer if we used semantic versioning and stopped releasing major versions with a bump of the minor version number.

I weekly support this, as it is my preferred scheme, and all OSS tools
already understand those *very* well indeed. But I wouldn't want to
enforce it for this July. :slight_smile:

Maybe we can think of 4.0 as the last of the "weird major release",
and plan well in advance to move to 5.0 when we're ready, not when the
clock ticked. But that could bring a whole lot of other things like
holding off features during code freeze, have multiple branches in Git
for experimental features, etc. which I'd *also* welcome, but all in
good time. Let's move to Git-only first.

We might use the introduction of the new pass manager structure as the excuse for a mayor release (that should have some reasonable impact on the organization of the optimizations) or perhaps claim moving to Git as a mayor step (though I guess that that's more of an organizational element)?

Cheers,
  Roel

> 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.

Hi Rafael,

The main issue I see with automatically moving to 4.0, is that if a year
from now we decide we want to drop a bitcode feature, we can't really do
it unless we bump the major version again to 5.0. If we continue on
with 3.x, then we still have the flexibility to drop bitcode features
when we decide it's necessary.

-Tom

From: cfe-dev [mailto:cfe-dev-bounces@lists.llvm.org] On Behalf Of Tom
Stellard via cfe-dev
Sent: Monday, June 13, 2016 7:12 AM
To: Rafael Espíndola
Cc: llvm-dev; Release-testers; openmp-dev (openmp-dev@lists.llvm.org);
LLDB Dev; cfe-dev
Subject: Re: [cfe-dev] [llvm-dev] [3.9 Release] Release plan and call for
testers

> > 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.
>

Hi Rafael,

The main issue I see with automatically moving to 4.0, is that if a year
from now we decide we want to drop a bitcode feature, we can't really do
it unless we bump the major version again to 5.0. If we continue on
with 3.x, then we still have the flexibility to drop bitcode features
when we decide it's necessary.

-Tom

+1. My understanding is that 2.9->3.0 came with some huge internal changes
(overhaul of the type system, maybe? this slightly predates my involvement
with LLVM so I'm not entirely sure) and warranted a major-version change
regardless of the .9->.0 thing.

I don't think 3.10 should be confusing to anyone, really. The version
number is a tuple, not a string or a decimal fraction.
--paulr

+1. My understanding is that 2.9->3.0 came with some huge internal changes
(overhaul of the type system, maybe? this slightly predates my involvement
with LLVM so I'm not entirely sure) and warranted a major-version change
regardless of the .9->.0 thing.

1->2 also came with a fairly fundamental change (removal of signed and unsigned integer types, addition of signed and unsigned integer operations).

I don't think 3.10 should be confusing to anyone, really. The version
number is a tuple, not a string or a decimal fraction.

Agreed.

David

OK, I guess that is where your reading of the version differ.

I read that we promise that 4.0 will read all of 3.X, but make no
further promises. That means that in 4.1 we *can* drop support for all
3.x, keep support for everything or something in the middle. But that
is also true for 4.2. So for example it would be valid that

* 4.0 reads all of 3.x
* 4.1 reads >= 3.1
* 4.2 reads >= 3.3

Cheers,
Rafael

From: llvm-dev [mailto:llvm-dev-bounces@lists.llvm.org] On Behalf Of
Rafael Espíndola via llvm-dev
Sent: Monday, June 13, 2016 7:47 AM
To: Tom Stellard
Cc: llvm-dev; Release-testers; openmp-dev (openmp-dev@lists.llvm.org);
LLDB Dev; cfe-dev
Subject: Re: [llvm-dev] [3.9 Release] Release plan and call for testers

>> > 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.
>>
>
> Hi Rafael,
>
> The main issue I see with automatically moving to 4.0, is that if a year
> from now we decide we want to drop a bitcode feature, we can't really do
> it unless we bump the major version again to 5.0. If we continue on
> with 3.x, then we still have the flexibility to drop bitcode features
> when we decide it's necessary.

OK, I guess that is where your reading of the version differ.

I read that we promise that 4.0 will read all of 3.X, but make no
further promises. That means that in 4.1 we *can* drop support for all
3.x, keep support for everything or something in the middle. But that
is also true for 4.2. So for example it would be valid that

* 4.0 reads all of 3.x
* 4.1 reads >= 3.1
* 4.2 reads >= 3.3

I don't know that the actual policy has ever been formally documented,
although it has been discussed from time to time, so it's not too
surprising that people have different ideas of what the policy is.

Maybe documenting the release-numbering-semantics policy alongside
the release-timing policy would be a good idea?
--paulr

If someone could just let me know what the policy actually is.. :wink:

I think this is probably a case where the best approach is to write up
*some* kind of policy, and then it gets thrashed out in review.
--paulr

There isn't one. Never was. The *big* changes from 1.x to 2.x and 2.x
to 3.x were coincidental at best. There was no effort to hold features
until "the next big release comes out", like GCC.

However, I do want us to change to follow what almost all other OSS
projects do, so writing it as a policy now may discourage that change
and give folks some comfort that their idea has merits.

I fundamentally agree with David that we have a poor way of naming
releases, and that messes up a lot of infrastructure out there.

But we do have one policy, which is to warn of any potentially
damaging change with *at least* one release in advance.

Until now, we always moved from x.9 to (x+1).0. Not because it was a
rule or was written somewhere, but because we did. So, doing it again
will yield no surprise. If, OTOH, we create a 3.10, it will be our
first two-digit release, and that may, actually, break stuff
downstream.

So, my proposal on IRC was the following:

1. Get over it, call it 4.0 and release 3.9 as scheduled.
2. *Just after* the release, start the discussion for 5.0

This way we'll have at least 5 years to get it right, and people will
know (we can document that) that changes are coming. But we can also
change from (ex) 4.3 to 5.0 as soon as we agree that we'll do that.

My point for the delay is two-fold:

1. Changing the number is not just about naming, it's about behaviour.
We'll be telling the world that Clang/LLVM 3.x should work with *any*
3.x components, which is *not* true today.
2. We'll give time for people to agree or disagree, before we name the
release on SVN. People release Git-versions of LLVM and call them
"llvm-3.9-git". Imagine if we create "llvm-3.10-git" but we decide to
change later on to 4.0?

So, let's discuss about code freeze, feature branches, stable
releases, etc, *first*. But for that, it'd be good to get the SVN vs.
Git out of the way even sooner, so, we're talking years, here...

cheers,
--renato

I don't know that the actual policy has ever been formally documented,
although it has been discussed from time to time, so it's not too
surprising that people have different ideas of what the policy is.

Maybe documenting the release-numbering-semantics policy alongside
the release-timing policy would be a good idea?

It is documented at

http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility

Cheers,
Rafael

This is weird...

"The bitcode format produced by a X.Y release will be readable by all
following X.Z releases and the (X+1).0 release."

Why (x+1).0 ?

--renato

It would probably better for whoever wrote this text to pipe in, but I think the idea is that (X+1).0 is supposed to be a kind of a “bridge” release.

That is, if you have legacy IR files that contain dropped features, or if the IR format changed significantly, you can still use the (X+1).0 auto-upgrade (which may be fairly complex) to read them, but this auto-upgrade complexity may be dropped in (X+1).1.
I’m not completely sure this makes sense, but this is how I’ve always understood it.