[4.0 Release] Schedule and call for testers

Dear everyone,

There's still plenty of time left, but I'd like to get the schedule
set before folks start disappearing for the holidays.

Note that this release will also switch us to the new versioning
scheme where the major version is incremented for each major release
(i.e., when the 4.0 branch is created, trunk will become 5.0).

If you'd like to help providing binaries and testing for your
favourite platform, please subscribe to the release-testers mailing
list [1].

I propose the following schedule for the 4.0 release:

- 12 January 2017: Create the 4.0 branch. RC1 tagged soon thereafter.

- 1 February: Tag RC2. All lose ends should have been tied up by now.

- 21 February: Final tag. Binaries and release announcement a few days later.

Unless there are any objections, I'll post this on the web page soon.

Cheers,
Hans

  [1] http://lists.llvm.org/mailman/listinfo/release-testers

LGTM.

--renato

There's still plenty of time left, but I'd like to get the schedule
set before folks start disappearing for the holidays.

Note that this release will also switch us to the new versioning
scheme where the major version is incremented for each major release
(i.e., when the 4.0 branch is created, trunk will become 5.0).

Maybe I didn't pay enough attention, but where is the general outline
for this versioning scheme documented? And are we still going to do
4.1, 4.2, etc?

If you'd like to help providing binaries and testing for your
favourite platform, please subscribe to the release-testers mailing
list [1].

I propose the following schedule for the 4.0 release:

- 12 January 2017: Create the 4.0 branch. RC1 tagged soon thereafter.

- 1 February: Tag RC2. All lose ends should have been tied up by now.

- 21 February: Final tag. Binaries and release announcement a few days later.

Unless there are any objections, I'll post this on the web page soon.

Note that this is a pretty close follow-up to the 3.9.1 release. There
is a minor risk of "release burn-out" here... :slight_smile:

Otherwise, LGTM.

-Dimitry

There's still plenty of time left, but I'd like to get the schedule
set before folks start disappearing for the holidays.

Note that this release will also switch us to the new versioning
scheme where the major version is incremented for each major release
(i.e., when the 4.0 branch is created, trunk will become 5.0).

Maybe I didn't pay enough attention, but where is the general outline
for this versioning scheme documented? And are we still going to do
4.1, 4.2, etc?

There was a long discussion around the time when the 3.9 branch was
created. I'm planning on writing a blog post to make sure everyone is
up to date.

The idea is that Tom's stable releases will keep incrementing the
"patch" part of the version numbers, just as today, so they would be
4.0.1, 4.0.2, etc.

If you'd like to help providing binaries and testing for your
favourite platform, please subscribe to the release-testers mailing
list [1].

I propose the following schedule for the 4.0 release:

- 12 January 2017: Create the 4.0 branch. RC1 tagged soon thereafter.

- 1 February: Tag RC2. All lose ends should have been tied up by now.

- 21 February: Final tag. Binaries and release announcement a few days later.

Unless there are any objections, I'll post this on the web page soon.

Note that this is a pretty close follow-up to the 3.9.1 release. There
is a minor risk of "release burn-out" here... :slight_smile:

Hopefully 3.9.1 will be done some time before 4.0.0 starts, otherwise
I agree that's not very good for the testers. I don't want to change
the schedule of the major releases though, as we've been on a nice
predictible 6-month cycle for a while now.

Thanks,
Hans

Maybe I didn't pay enough attention, but where is the general outline
for this versioning scheme documented? And are we still going to do
4.1, 4.2, etc?

This is the thread:

http://lists.llvm.org/pipermail/llvm-dev/2016-June/101044.html

Note that this is a pretty close follow-up to the 3.9.1 release. There
is a minor risk of "release burn-out" here... :slight_smile:

They're completely different trees, so should only be a problem if we
haven't finished by then.

3.9.1 convergence took a lot longer than expected because of the
number of back-ports. With interest in the point-releases growing, I
think we should try a "half-way" schedule for the point releases, to
make sure that doesn't happen again.

cheers,
--renato

Hum, this looks weird. I was under the impression that we'd do 4.1, 4.2 instead.

Otherwise, it'll be:

* 3.9.0
* 3.9.1
* 4.0.0
* 4.0.1
* 5.0.0
* 5.0.1

With a totally redundant zero in the middle.

Unless we're planning to extend the maintenance of the 5.x branch and
release 5.1.0 *after* 6.0.0 is out, which would be a major change in
how we release LLVM. I don't think that's the plan.

cheers,
--renato

Will this new version scheme mean that 4.1 (if ever released) will be
ABI-compatible with 4.0? If it will be so, we should update SONAMEs
accordingly.

The idea is that Tom's stable releases will keep incrementing the
"patch" part of the version numbers, just as today, so they would be
4.0.1, 4.0.2, etc.

Hum, this looks weird. I was under the impression that we'd do 4.1, 4.2 instead.

I'd like to avoid 4.1 because of the potential for confusion about
whether it's a major release (as it would have been under the old
scheme) or a patch release.

Otherwise, it'll be:

* 3.9.0
* 3.9.1
* 4.0.0
* 4.0.1
* 5.0.0
* 5.0.1

With a totally redundant zero in the middle.

Yes, it has a redundant zero in the middle, but I don't think that's a
terrible thing, and it's very clear what the version number means.

The alternative would be:

3.9.0
3.9.1
4.0.0
4.1.0 <-- Can't tell from the version number what kind of release this is.

Unless we're planning to extend the maintenance of the 5.x branch and
release 5.1.0 *after* 6.0.0 is out, which would be a major change in
how we release LLVM. I don't think that's the plan.

Right, not planning to do that.

Yes. All 4.x will be ABI compatible with 4.0, just like any stable
release we do today. Doesn't matter if it's called 4.0.1 or 4.1.

cheers,
--renato

Just keep two digits. X.Y and drop .Z completely.

I'd like to avoid 4.1 because of the potential for confusion about
whether it's a major release (as it would have been under the old
scheme) or a patch release.

But if the versioning scheme is different, users will have to
understand what it means anyway.

Until now we had a weird and very unique logic, and we're moving to a
more sensible logic, because it's similar to what some other projects
are doing.

I can see as much confusion from 4.0.1 -> 5.0.0 than by having a 4.1
that used to be weird before.

After a few releases everything will be clear anyway... I really don't
want to make the foreseeable future weird again to avoid a potential
misunderstanding for one or two releases.

Let's just be brutally clear in all release communications and
hopefully people will understand.

The alternative would be:

3.9.0
3.9.1
4.0.0
4.1.0 <-- Can't tell from the version number what kind of release this is.

No, that has a redundant zero, too.

The alternative is:

3.9.0
3.9.1
4.0
4.1
5.0
5.1

etc.

cheers,
--renato

I'm worried that users will, with some reason, think that the 4.1 and
5.1 releases are the same kind as 2.1 and 3.1 :-/

Hi,
plan looks good to me.
At OpenMandriva, we’re already on the 4.0 branch (rev. 287544 right now) because that’s what our next major release (expected in late Q2/early Q3 2017) will ship with.

No big issues here so far, except the LLVMAddAttribute removal (Mesa still relies on that API – we’ve solved it for now by patching it back in). We’ll probably upgrade our snapshot one more time in mid to late December, then package RC1, RC2 and final (and any RC3 or so that might be added).

In the Android world, we’re running daily builds of AOSP master with clang master inside Linaro. No big issues there either (some extra warnings emitted by 4.0, esp. address-of-packed-member required some code changes and/or -Wno-error= workarounds, but that’s intentional).

ttyl
bero

IMO, this is too small of a worry to encumber us for the rest of our
release days with silly zeroes.

I'd rather be redundantly explicit for the next year, than carry that
burden for the next 5 (or more).

cheers,
--renato

I'm worried that users will, with some reason, think that the 4.1 and
5.1 releases are the same kind as 2.1 and 3.1 :-/

IMO, this is too small of a worry to encumber us for the rest of our
release days with silly zeroes.

For me, it's a big worry, and I'm positive lots of developers (and any
code trying to parse our version numbers) would be confused by
dropping it.

I don't think having a redundant zero in the middle is a big problem:
we used to make minor releases but now we don't, so it stays at zero.
(And if for some reason we'd want to do one in the future, we could.)

This is the scheme we arrived at at the end of the great version
number discussion this summer, and I don't see any reason to change it
now.

I'd rather be redundantly explicit for the next year, than carry that
burden for the next 5 (or more).

Sure, if we think this is terribly annoying in the future and we
decide dropping the unused "minor" part of our version number is the
best thing, we could attempt it at that point. I'm not doing anything
now that would make that harder.

Thanks,
Hans

+1, I haven’t seen yet the downside of keeping the minor to 0 and bumping only the patch number.

Just do 4a, 4b, 4c ;-). Everyone will be as confused as possible ;-).

> Maybe I didn't pay enough attention, but where is the general outline
> for this versioning scheme documented? And are we still going to do
> 4.1, 4.2, etc?

This is the thread:

http://lists.llvm.org/pipermail/llvm-dev/2016-June/101044.html

> Note that this is a pretty close follow-up to the 3.9.1 release. There
> is a minor risk of "release burn-out" here... :slight_smile:

They're completely different trees, so should only be a problem if we
haven't finished by then.

3.9.1 convergence took a lot longer than expected because of the
number of back-ports. With interest in the point-releases growing, I
think we should try a "half-way" schedule for the point releases, to
make sure that doesn't happen again.

We are actually pretty close to a halfway schedule for the stable
releases right now. 3.9.0 was released Sep 2, and the 3.9.1
release was scheduled for December 5 (though it's running behind as
usual).

It just seems close together because the major release process has
a longer period of RC releases and stablilization.

-Tom

From: cfe-dev [mailto:cfe-dev-bounces@lists.llvm.org] On Behalf Of Michal
Górny via cfe-dev
Sent: Monday, December 05, 2016 3:33 PM
To: Hans Wennborg via lldb-dev
Cc: llvm-dev; Release-testers; openmp-dev (openmp-dev@lists.llvm.org);
cfe-dev
Subject: Re: [cfe-dev] [lldb-dev] [Release-testers] [Openmp-dev] [4.0
Release] Schedule and call for testers

> >> I'd like to avoid 4.1 because of the potential for confusion about
> >> whether it's a major release (as it would have been under the old
> >> scheme) or a patch release.
> >
> > But if the versioning scheme is different, users will have to
> > understand what it means anyway.
> >
> > Until now we had a weird and very unique logic, and we're moving to a
> > more sensible logic, because it's similar to what some other projects
> > are doing.
> >
> > I can see as much confusion from 4.0.1 -> 5.0.0 than by having a 4.1
> > that used to be weird before.
> >
> > After a few releases everything will be clear anyway... I really don't
> > want to make the foreseeable future weird again to avoid a potential
> > misunderstanding for one or two releases.
> >
> > Let's just be brutally clear in all release communications and
> > hopefully people will understand.
> >
> >
> >> The alternative would be:
> >>
> >> 3.9.0
> >> 3.9.1
> >> 4.0.0
> >> 4.1.0 <-- Can't tell from the version number what kind of release
this is.
> >
> > No, that has a redundant zero, too.
> >
> > The alternative is:
> >
> > 3.9.0
> > 3.9.1
> > 4.0
> > 4.1
> > 5.0
> > 5.1
>
> I'm worried that users will, with some reason, think that the 4.1 and
> 5.1 releases are the same kind as 2.1 and 3.1 :-/

Just do 4a, 4b, 4c ;-). Everyone will be as confused as possible ;-).

Back in the day, every version was identified as "Latest."
No possible confusion there!

I'm fine with "4.0.1" in keeping with the major.minor.patch convention,
given how the in-betweeners are really patch updates not minor versions.
--paulr

I hope you could branch and tag to projects atomically. Are you able?