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

Cristianno Martins via llvm-dev llvm-dev at lists.llvm.org
Tue Jun 14 21:21:24 PDT 2016

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

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>

More information about the llvm-dev mailing list