llvm dev - Jun 2016 - [cfe-dev] [lldb-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

On Tue, Jun 14, 2016 at 11:51 AM, Eric Christopher via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
>
>
> On Tue, Jun 14, 2016 at 12:43 AM Chandler Carruth via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> On Mon, Jun 13, 2016 at 5:03 PM Hal Finkel via lldb-dev <
>> lldb-dev at lists.llvm.org> wrote:
>>
>>> ----- Original Message -----
>>> > From: "Hans Wennborg via cfe-dev" <cfe-dev at
lists.llvm.org>
>>> > To: "llvm-dev" <llvm-dev at lists.llvm.org>,
"cfe-dev" <
>>> cfe-dev at lists.llvm.org>, "LLDB Dev" <lldb-dev at
lists.llvm.org>,
>>> > "openmp-dev (openmp-dev at lists.llvm.org)"
<openmp-dev at lists.llvm.org>
>>> > Cc: "r jordans" <r.jordans at tue.nl>,
"Paul Robinson" <
>>> Paul_Robinson at playstation.sony.com>
>>> > Sent: Monday, June 13, 2016 6:54:19 PM
>>> > Subject: [cfe-dev] What version comes after 3.9? (Was: [3.9
Release]
>>> Release plan and call for testers)
>>> >
>>> > Breaking this out into a separate thread since it's kind
of a
>>> > separate
>>> > issue, and to make sure people see it.
>>> >
>>> > If you have opinions on this, please chime in. I'd like to
collect as
>>> > many arguments here as possible to make a good decision. The
main
>>> > contestants are 4.0 and 3.10, and I've seen folks being
equally
>>> > surprised by both.
>>> >
>>> > Brain-dump so far:
>>> >
>>> > - After LLVM 1.9 came 2.0, and after 2.9 came 3.0; naturally,
4.0
>>> > comes after 3.9.
>>> >
>>> > - There are special bitcode stability rules [1] concerning
major
>>> > version bumps. 2.0 and 3.0 had major IR changes, but since
there
>>> > aren't any this time, we should go to 3.10.
>>> >
>>> > - The bitcode stability rules allow for breakage with major
versions,
>>> > but it doesn't require it, so 4.0 is fine.
>>> >
>>> > - But maybe we want to save 4.0 for when we do have a
significant IR
>>> > change?
>>>
>>> I think that this is the right approach, and we happen to have a
natural
>>> forcing function here: opaque pointer types. I think we should
increment
>>> the major version number when opaque pointer types are here, as it
will be
>>> a major breaking change, and then we'll have a version 4.0.
Until then,
>>> unless something else breaking comes up, 3.10 sounds fine to me.
>>>
>>
>> +1, complete agreement.
>>
>
> While I'm not sure opaque pointer types are going to increment versions
> I'm also in agreement that 3.10 is the right way to go.
>
+1

-- Sean Silva

>
> -eric
>
>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160614/f2add77c/attachment.html>

Hello there,

First, I would like to say that I don't have any strong opinions on this
matter: as mostly an user of LLVM, my basic concern is for me to be able to
identify which version is the newest and configure it as easily as
possible. That being said, I have a question about LLVM's versioning
strategy: is it possible for other tools (including the ones LLVM depend
on) to become broke or annoyingly buggy just because a bad versioning
scheme was put in place?

Just to give some context to this question, I've been using OS X for a
while, and I confess I was pretty annoyed when OS X 10.9 was followed by OS
X 10.10. Not at first, no: I didn't realize this would have any impact on
my workspace until I had to compile some code, and CMake kept stopping just
because it recognized that I was using an older version of the OS (emphasis
on *older*). It is funny when you realize that 10.10 should actually be
interpreted as less than 10.9, and CMake was falling for it, which was a
wrong behavior of the tool, I admit, but the weird OS versioning scheme was
the main cause of this issue. Of course this problem can be easily arranged
by setting up some extra environment variables to tell CMake to target OS X
10.9 instead, but that was a very irritating behavior and only happened
because a bunch of people (from CMake, and, then, from OS X's development
team) thought comparing versions directly shouldn't be a problem. Besides,
every one of these small details end up being some extra steps a new user
need to follow to be able to use a tool, some of which could be easily
avoided.

I confess I didn't look into this matter after that, and still today, on OS
X 10.11, I'm targeting version 10.9 on all my CMake runs on OS X -- thus, I
don't know if this bug was fixed or not. However, as I'm starting to see
a
very similar pattern happening with LLVM on this thread, and I thought I
could contribute with the discussion: did someone check if naming the next
version "3.10" would have any impact on a production system?


--
Cristianno Martins
<cristiannomartins at hotmail.com>

On Tue, Jun 14, 2016 at 10:48 PM, Sean Silva via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
>
> On Tue, Jun 14, 2016 at 11:51 AM, Eric Christopher via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>>
>>
>> On Tue, Jun 14, 2016 at 12:43 AM Chandler Carruth via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>> On Mon, Jun 13, 2016 at 5:03 PM Hal Finkel via lldb-dev <
>>> lldb-dev at lists.llvm.org> wrote:
>>>
>>>> ----- Original Message -----
>>>> > From: "Hans Wennborg via cfe-dev" <cfe-dev at
lists.llvm.org>
>>>> > To: "llvm-dev" <llvm-dev at
lists.llvm.org>, "cfe-dev" <
>>>> cfe-dev at lists.llvm.org>, "LLDB Dev"
<lldb-dev at lists.llvm.org>,
>>>> > "openmp-dev (openmp-dev at lists.llvm.org)"
<openmp-dev at lists.llvm.org>
>>>> > Cc: "r jordans" <r.jordans at tue.nl>,
"Paul Robinson" <
>>>> Paul_Robinson at playstation.sony.com>
>>>> > Sent: Monday, June 13, 2016 6:54:19 PM
>>>> > Subject: [cfe-dev] What version comes after 3.9? (Was:
[3.9 Release]
>>>> Release plan and call for testers)
>>>> >
>>>> > Breaking this out into a separate thread since it's
kind of a
>>>> > separate
>>>> > issue, and to make sure people see it.
>>>> >
>>>> > If you have opinions on this, please chime in. I'd
like to collect as
>>>> > many arguments here as possible to make a good decision.
The main
>>>> > contestants are 4.0 and 3.10, and I've seen folks
being equally
>>>> > surprised by both.
>>>> >
>>>> > Brain-dump so far:
>>>> >
>>>> > - After LLVM 1.9 came 2.0, and after 2.9 came 3.0;
naturally, 4.0
>>>> > comes after 3.9.
>>>> >
>>>> > - There are special bitcode stability rules [1] concerning
major
>>>> > version bumps. 2.0 and 3.0 had major IR changes, but since
there
>>>> > aren't any this time, we should go to 3.10.
>>>> >
>>>> > - The bitcode stability rules allow for breakage with
major versions,
>>>> > but it doesn't require it, so 4.0 is fine.
>>>> >
>>>> > - But maybe we want to save 4.0 for when we do have a
significant IR
>>>> > change?
>>>>
>>>> I think that this is the right approach, and we happen to have
a
>>>> natural forcing function here: opaque pointer types. I think we
should
>>>> increment the major version number when opaque pointer types
are here, as
>>>> it will be a major breaking change, and then we'll have a
version 4.0.
>>>> Until then, unless something else breaking comes up, 3.10
sounds fine to me.
>>>>
>>>
>>> +1, complete agreement.
>>>
>>
>> While I'm not sure opaque pointer types are going to increment
versions
>> I'm also in agreement that 3.10 is the right way to go.
>>
>
> +1
>
> -- Sean Silva
>
>
>>
>> -eric
>>
>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160615/8364d970/attachment.html>

Bug in cmake (or more likely the makefile?), pure and simple. Version
numbers aren't strings, and they aren't floating point numbers, they are
a
series of integers separated by dots. I can't think of a project where
interpreting version numbers that way won't work.

On Wed, Jun 15, 2016 at 7:21 AM, Cristianno Martins via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hello there,
>
> First, I would like to say that I don't have any strong opinions on
this
> matter: as mostly an user of LLVM, my basic concern is for me to be able to
> identify which version is the newest and configure it as easily as
> possible. That being said, I have a question about LLVM's versioning
> strategy: is it possible for other tools (including the ones LLVM depend
> on) to become broke or annoyingly buggy just because a bad versioning
> scheme was put in place?
>
> Just to give some context to this question, I've been using OS X for a
> while, and I confess I was pretty annoyed when OS X 10.9 was followed by OS
> X 10.10. Not at first, no: I didn't realize this would have any impact
on
> my workspace until I had to compile some code, and CMake kept stopping just
> because it recognized that I was using an older version of the OS (emphasis
> on *older*). It is funny when you realize that 10.10 should actually be
> interpreted as less than 10.9, and CMake was falling for it, which was a
> wrong behavior of the tool, I admit, but the weird OS versioning scheme was
> the main cause of this issue. Of course this problem can be easily arranged
> by setting up some extra environment variables to tell CMake to target OS X
> 10.9 instead, but that was a very irritating behavior and only happened
> because a bunch of people (from CMake, and, then, from OS X's
development
> team) thought comparing versions directly shouldn't be a problem.
Besides,
> every one of these small details end up being some extra steps a new user
> need to follow to be able to use a tool, some of which could be easily
> avoided.
>
> I confess I didn't look into this matter after that, and still today,
on
> OS X 10.11, I'm targeting version 10.9 on all my CMake runs on OS X --
> thus, I don't know if this bug was fixed or not. However, as I'm
starting
> to see a very similar pattern happening with LLVM on this thread, and I
> thought I could contribute with the discussion: did someone check if naming
> the next version "3.10" would have any impact on a production
system?
>
>
> --
> Cristianno Martins
> <cristiannomartins at hotmail.com>
>
> On Tue, Jun 14, 2016 at 10:48 PM, Sean Silva via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>>
>>
>> On Tue, Jun 14, 2016 at 11:51 AM, Eric Christopher via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>>
>>>
>>> On Tue, Jun 14, 2016 at 12:43 AM Chandler Carruth via cfe-dev <
>>> cfe-dev at lists.llvm.org> wrote:
>>>
>>>> On Mon, Jun 13, 2016 at 5:03 PM Hal Finkel via lldb-dev <
>>>> lldb-dev at lists.llvm.org> wrote:
>>>>
>>>>> ----- Original Message -----
>>>>> > From: "Hans Wennborg via cfe-dev"
<cfe-dev at lists.llvm.org>
>>>>> > To: "llvm-dev" <llvm-dev at
lists.llvm.org>, "cfe-dev" <
>>>>> cfe-dev at lists.llvm.org>, "LLDB Dev"
<lldb-dev at lists.llvm.org>,
>>>>> > "openmp-dev (openmp-dev at lists.llvm.org)"
<openmp-dev at lists.llvm.org>
>>>>> > Cc: "r jordans" <r.jordans at tue.nl>,
"Paul Robinson" <
>>>>> Paul_Robinson at playstation.sony.com>
>>>>> > Sent: Monday, June 13, 2016 6:54:19 PM
>>>>> > Subject: [cfe-dev] What version comes after 3.9? (Was:
[3.9 Release]
>>>>> Release plan and call for testers)
>>>>> >
>>>>> > Breaking this out into a separate thread since
it's kind of a
>>>>> > separate
>>>>> > issue, and to make sure people see it.
>>>>> >
>>>>> > If you have opinions on this, please chime in. I'd
like to collect as
>>>>> > many arguments here as possible to make a good
decision. The main
>>>>> > contestants are 4.0 and 3.10, and I've seen folks
being equally
>>>>> > surprised by both.
>>>>> >
>>>>> > Brain-dump so far:
>>>>> >
>>>>> > - After LLVM 1.9 came 2.0, and after 2.9 came 3.0;
naturally, 4.0
>>>>> > comes after 3.9.
>>>>> >
>>>>> > - There are special bitcode stability rules [1]
concerning major
>>>>> > version bumps. 2.0 and 3.0 had major IR changes, but
since there
>>>>> > aren't any this time, we should go to 3.10.
>>>>> >
>>>>> > - The bitcode stability rules allow for breakage with
major versions,
>>>>> > but it doesn't require it, so 4.0 is fine.
>>>>> >
>>>>> > - But maybe we want to save 4.0 for when we do have a
significant IR
>>>>> > change?
>>>>>
>>>>> I think that this is the right approach, and we happen to
have a
>>>>> natural forcing function here: opaque pointer types. I
think we should
>>>>> increment the major version number when opaque pointer
types are here, as
>>>>> it will be a major breaking change, and then we'll have
a version 4.0.
>>>>> Until then, unless something else breaking comes up, 3.10
sounds fine to me.
>>>>>
>>>>
>>>> +1, complete agreement.
>>>>
>>>
>>> While I'm not sure opaque pointer types are going to increment
versions
>>> I'm also in agreement that 3.10 is the right way to go.
>>>
>>
>> +1
>>
>> -- Sean Silva
>>
>>
>>>
>>> -eric
>>>
>>>
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> cfe-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>>
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160616/acb588fc/attachment.html>