> On Jun 18, 2016, at 9:16 PM, Chris Lattner via llvm-dev > <llvm-...@lists.llvm.org> wrote: > > On Jun 14, 2016, at 1:32 AM, Richard Smith via cfe-dev > <cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>> wrote: >> 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. > > I completely agree with Richard here. “Breaking of IR compatibility” was an > interesting metric for older and less mature versions of LLVM. We can solve > the same sort of challenge (the desire to eject old autoupgrade code) by > having a sliding window of versions supported (e.g. version 4.5 supports back > to version 3.6).
Let me clarify. What I’m trying to say is that: a) LLVM has a time-based release cycle, not a schedule-based one. As such, a simple and predictable version number makes sense. b) The LLVM project as a whole is a lot bigger than LLVM IR, even given its centrality to the project in some ways. c) I think that it makes sense to keep adding 0.1 to each major release going forward well into the future. On the topic of the pointer changes proposed, I really don’t think the community is served by waiting for that. The supposition seems to be that we’d land it *without* upgrade support, but then bump the major version number to indicate this. If that’s the proposal, I think that doing such a thing would be disastrous for the LLVM community as a whole: we need to have at least some sliding window of support for older formats. -Chris
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
