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

[Mehdi Amini via cfe-dev]

> On Jun 13, 2016, at 4:54 PM, Hans Wennborg <hans at chromium.org> wrote:
> 
> Breaking this out into a separate thread since it's kind of a separate
> issue, and to make sure people see it.

Thanks!

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

(basically repeating my point of the other thread here)
Bumping the major version number without changing the bitcode compatibility rule would mean dropping the current guarantee on this aspect. I doubt we want to go this route without a good reason.

-- 
Mehdi


> 
> - But maybe we want to save 4.0 for when we do have a significant IR change?
> 
> - 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