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

[Adve, Vikram Sadanand via llvm-dev]

> On Jun 19, 2016, at 4:25 AM, via llvm-dev <llvm-dev at lists.llvm.org> wrote:
<snip>
> 
>>>> 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.


Now you’re making the versions sound like floating point numbers :-).  Just to be clear, you are proposing we use 3.10/3.11/etc. rather than 4.0/4.1/etc.?

If so, I agree with that for a couple of reasons.  First, as several people said, version numbers should not be driven primarily by IR changes: the LLVM project is a lot more than the IR, even though the IR is a fundamental component.  Our releases are time-based and the predictability of that has worked pretty well.

A second reason is that major version numbers also have a useful 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 turn out to be the next major change -- but regardless of what the change is, I think there is some value in reserving major version increments (like 3.x.y to 4.0) when major changes happen.

--Vikram


> 
>> 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. 
> 
> -Hal 


-—Vikram

// Vikram S. Adve
// Professor, Department of Computer Science
// University of Illinois at Urbana-Champaign
// vadve at illinois.edu
// http://llvm.org