[llvm-dev] [Openmp-dev] [cfe-dev] [lldb-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
Mehdi Amini via llvm-dev
llvm-dev at lists.llvm.org
Tue Jun 28 15:20:31 PDT 2016
> On Jun 28, 2016, at 4:16 PM, Rafael Espíndola via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>> The promise just says that 4.0 *will* read 3.X and 4.1 might.
>> Yes, but while you have read it and interpreted it precisely, I suspect that
>> many people have misinterpreted it and assume that 4.0 will be the last
>> release to read 3.X. They may be incorrect, but I think it would still be
>> worth considering them and working to communicate this effectively.
>> Essentially, what Eric said: it may be accurate, but it isn't *obvious*, at
>> least not to everyone.
> So lets fix that. What is your preference of wording? Specially if we
> go to a single integer model?
Just writing this: "The current LLVM version support loading any bitcode since version 3.0” would be enough to me.
I don’t feel the need to be explicit on a transition / deprecation period for now, we can elaborate when the time will come if really necessary.
Alternatively, we can add something like: “Any change to this policy will be anounced two releases ahead (i.e. the release notes for version x anounces the compatibility changes for version x+2).”.
>>> I think I agree with Chris with 3.10 being the worst possible outcome.
>> I'd be interested to understand why you or Chris thing 3.10 is the worst
>> possible outcome.
>> Chris has said it is because he thinks we'll never change the "3", but I
>> don't understand why 3.10 is worse than 3.9 was in that respect. I happen to
>> agree that we'll never change the "3", but I don't think this makes 3.10 a
>> particularly bad choice.
> It makes the "3." look more significant than it is and we will keep
> having discussions about what is "major" in the future.
>> I'm seeing pretty much zero support for continuing to have a major/minor
>> split. As such, I pretty strongly suggest that as a community we move to a
>> single integer that increments every (time based) release, and a .N that
>> increments with every patch release off of that branch. GCC and numerous
>> other projects work this way.
> I like this. And that is why I don't like the 3.10. It makes the major
> number seem more significant than it looks currently (we avoided
> changing it after all).
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
More information about the llvm-dev