> On Jun 19, 2016, at 12:25 AM, Hal Finkel <hfin...@anl.gov> wrote:
>
> 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
> To be clear, that's not at all what I was saying. The plan has always been to
> have upgrade support. My thought was that once the pointer changes land, it
> will mean major changes in how many frontends and IR transformations use the
> API. A lot of out-of-tree frontends and passes support multiple versions of
> LLVM, and use ifdefs to work around relevant API changes. For the most part,
> this works reasonably, and the changes necessary between versions are not
> often large (perhaps especially because we have time-based releases). I
> suspect, however, that the amount of code changes necessary to adapt for the
> pointer changes will be much larger, and so calling that a new major version
> seems fitting.
API breakage isn’t a concern, every release of LLVM breaks APIs. I don’t see
a reason to “delay” LLVM 4.0.
-Chris
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
