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

[Bruce Hoult via cfe-dev]

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/cfe-dev/attachments/20160616/acb588fc/attachment.html>