Date: Tue, 14 Jun 2016 07:43:17 +0000
From: Chandler Carruth via llvm-dev <llvm-dev@lists.llvm.org>
To: Hal Finkel <hfinkel@anl.gov>, Hans Wennborg <hans@chromium.org>
Cc: llvm-dev <llvm-dev@lists.llvm.org>, "openmp-dev
\(openmp-dev@lists.llvm.org\)" <openmp-dev@lists.llvm.org>, LLDB Dev
<lldb-dev@lists.llvm.org>, cfe-dev <cfe-dev@lists.llvm.org>, Paul
Robinson <Paul_Robinson@playstation.sony.com>
Subject: Re: [llvm-dev] [lldb-dev] [cfe-dev] What version comes after
3.9? (Was: [3.9 Release] Release plan and call for testers)
Message-ID:
<CAGCO0Kiuxk_qnoXknFzHh3b71WLanux9FFnvPEFOX8emEJ0uFQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"From: "Hans Wennborg via cfe-dev" <cfe-dev@lists.llvm.org>
To: "llvm-dev" <llvm-dev@lists.llvm.org>, "cfe-dev" <cfe-dev@lists.llvm.org>, "LLDB Dev" <lldb-dev@lists.llvm.org>,
"openmp-dev (openmp-dev@lists.llvm.org)" <openmp-dev@lists.llvm.org>
Cc: "r jordans" <r.jordans@tue.nl>, "Paul Robinson" <Paul_Robinson@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.
I agree with the suggestion but for a different reason -- see below.
+1, complete agreement.
Date: Tue, 14 Jun 2016 01:32:30 -0700
From: Richard Smith via llvm-dev <llvm-dev@lists.llvm.org>
To: Hal Finkel <hfinkel@anl.gov>
Cc: llvm-dev <llvm-dev@lists.llvm.org>, "openmp-dev
\(openmp-dev@lists.llvm.org\)" <openmp-dev@lists.llvm.org>, LLDB Dev
<lldb-dev@lists.llvm.org>, cfe-dev <cfe-dev@lists.llvm.org>, Paul
Robinson <Paul_Robinson@playstation.sony.com>
Subject: Re: [llvm-dev] [cfe-dev] What version comes after 3.9? (Was:
[3.9 Release] Release plan and call for testers)From: "Hans Wennborg via cfe-dev" <cfe-dev@lists.llvm.org>
To: "llvm-dev" <llvm-dev@lists.llvm.org>, "cfe-dev" <cfe-dev@lists.llvm.org>, "LLDB Dev" <lldb-dev@lists.llvm.org>,
"openmp-dev (openmp-dev@lists.llvm.org)" <openmp-dev@lists.llvm.org>
Cc: "r jordans" <r.jordans@tue.nl>, "Paul Robinson" <Paul_Robinson@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.We're talking about version numbers for the entire LLVM project here, which
encompasses a lot more than LLVM IR, and for many parts of which LLVM IR is
utterly irrelevant. I'm not convinced that tying version numbers to
backwards-incompatible changes to IR is reasonable any more, and it doesn't
seem hard to explicitly document the oldest version with which we are
compatible (in fact, we need to do that regardless, whether we say it's
"the same major version" or "everything since 3.0" or whatever else).
I agree that the LLVM system is a lot more than the IR, and version numbers should not be driven primarily by IR changes. Our releases have indeed been time-based recently, and the predictability has worked pretty well.
However, major version numbers also have a communication value: signifying a major step forward in the system along some dimension. It just so happens that these major changes have been IR changes in the past -- and perhaps opaque pointer types will be the next major change -- but regardless of what the change is, I do think there is some value in reserving major version increments (like 3.xyz to 4.xyz) for major changes. 3.9 is not a fraction -- if it was, we would not have 3.7.1 etc. -- so there is really no reason not to increment 9 to 10 to 11 and so on until we reach a point of major change, whatever that may be.
--Vikram