llvm dev - Jun 2016 - [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.

Cheers,
Rafael

On 13 Jun 2016, at 14:14, Rafael Espíndola via cfe-dev <cfe-dev at
lists.llvm.org> wrote:
> 
>> 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.
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

On 13 June 2016 at 14:23, David Chisnall via lldb-dev
<lldb-dev at lists.llvm.org> wrote:
> 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. :)

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

On Mon, Jun 13, 2016 at 09:14:43AM -0400, Rafael Espíndola
wrote:
> > 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
> Cheers,
> Rafael

> -----Original Message-----
> From: cfe-dev [mailto:cfe-dev-bounces at 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 at lists.llvm.org);
> LLDB Dev; cfe-dev
> Subject: Re: [cfe-dev] [llvm-dev] [3.9 Release] Release plan and call for
> testers
> 
> On Mon, Jun 13, 2016 at 09:14:43AM -0400, Rafael Espíndola wrote:
> > > 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
> 
> > Cheers,
> > Rafael
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

On 13 June 2016 at 10:11, Tom Stellard <tom at stellard.net>
wrote:
> On Mon, Jun 13, 2016 at 09:14:43AM -0400, Rafael Espíndola wrote:
>> > 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

Cheers,
Rafael

> On Jun 13, 2016, at 6:14 AM, Rafael Espíndola via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
>> 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.
I don't see this way: it means that we stop supporting compatibility, even
if we don't aggressively remove the auto-upgradecode. It looks like an
important decision and we should not take it lightly.

-- 
Mehdi

> 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

I've split the version discussion off into a new thread ("What version
comes after 3.9?") and CC'd everyone discussing it here so far.

On Mon, Jun 13, 2016 at 11:23 AM, Mehdi Amini via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
>> On Jun 13, 2016, at 6:14 AM, Rafael Espíndola via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
>>
>>> 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.
>
> I don't see this way: it means that we stop supporting compatibility,
even if we don't aggressively remove the auto-upgradecode. It looks like an
important decision and we should not take it lightly.
>
> --
> Mehdi
>
>
>> 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
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev