On Tue, Jun 14, 2016 at 1:32 AM Richard Smith via cfe-dev < cfe-...@lists.llvm.org> wrote:
> On Mon, Jun 13, 2016 at 5:03 PM, Hal Finkel via cfe-dev < > cfe-...@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. >> > > 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). > > Given that our releases are time-based rather than feature-based, I don't > see a distinct major / minor version being anything other than arbitrary, > so I'd suggest we take 4.0 as our next release, 4.1 as the first patch > release on that, 5.0 as the next release after that, and so on. > This seems oddly familiar. So, one point is that LLVM's IR compatibility impacts more projects than many other things do: - Clang generates bitcode with '-flto' and cares about compatibility with it. - LLD imports bitcode for LTO and cares about compatibility with it. Certainly, LLDB and libc++ are both ... substantially less impacted. All that said, I'm not opposed to a dramatically simpler version numbering scheme which just counts cycles provided we also establish some strategy for marking the bitcode compatibility requirements. But I also don't see it as an important change to make right now. -Chandler > -Hal >> >> > >> > - We've never had an x.10 version before; maybe that would be >> > confusing? Perhaps it's simply time to move on (like Linux 2.6.39 -> >> > 3.0 and 3.19 -> 4.0). >> > >> > - Since we do time-based rather than feature-based releases, the >> > major >> > version number shouldn't mean anything special anyway (e.g. big IR >> > changes or not), so 4.0? >> > >> > - Everyone knows that after 9 comes 10, so 3.10 it is. The version is >> > a tuple after all. >> > >> > - Let's go for 4.0 now, and 5.0 after that. Then the "dot"-releases >> > in >> > between would correspond to minor version bumps, which would make >> > sense (and catch up with GCC!). >> > >> > - It's just a number, no big deal; flip a coin or something. >> > >> > What do you think? >> > >> > - Hans >> > >> > >> > [1]. >> > http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility >> > _______________________________________________ >> > cfe-dev mailing list >> > cfe-...@lists.llvm.org >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >> > >> >> -- >> Hal Finkel >> Assistant Computational Scientist >> Leadership Computing Facility >> Argonne National Laboratory >> _______________________________________________ >> 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 >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev