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
<cristiannomart...@hotmail.com>

On Tue, Jun 14, 2016 at 10:48 PM, Sean Silva via llvm-dev <
llvm-...@lists.llvm.org> wrote:

>
>
> On Tue, Jun 14, 2016 at 11:51 AM, Eric Christopher via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
>
>>
>>
>> On Tue, Jun 14, 2016 at 12:43 AM Chandler Carruth via cfe-dev <
>> cfe-...@lists.llvm.org> wrote:
>>
>>> On Mon, Jun 13, 2016 at 5:03 PM Hal Finkel via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
>>>> ----- Original Message -----
>>>> > From: "Hans Wennborg via cfe-dev" <cfe-...@lists.llvm.org>
>>>> > To: "llvm-dev" <llvm-...@lists.llvm.org>, "cfe-dev" <
>>>> cfe-...@lists.llvm.org>, "LLDB Dev" <lldb-dev@lists.llvm.org>,
>>>> > "openmp-dev (openmp-...@lists.llvm.org)" <openmp-...@lists.llvm.org>
>>>> > Cc: "r jordans" <r.jord...@tue.nl>, "Paul Robinson" <
>>>> paul_robin...@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-...@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Reply via email to