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

[Rafael Espíndola via llvm-dev]

> I'm sympathetic to the idea that we should move to a sliding window for IR
> compatibility if that's useful.
>
> However, I think it is a really big mistake to *have* a major version and
> just increment it arbitrarily without any associated "major" change. Lacking
> us explaining what we consider to be a major release, people will make
> assumptions that will inevitably lead to missed expectations.
>
> If we want to have a major/minor split, I think we need to have *some*
> guidance for what will constitute a major jump. I don't think it needs to
> necessarily be formulaic (like bitcode compatibility), it could be when a
> feature happens to be ready and happens to be decided by the community to be
> "big enough" we flip the major version and announce that feature happened to
> be ready. But we shouldn't just go from 3.9 to 4.0 because of some decimal
> correspondence. Too many people will assume it had significance and become
> disappointed.
>
> If we *don't* want a major/minor split, then I believe Richard's suggestion
> is the correct one: just have integers to mark the temporal releases, and
> dot releases for updates to that release branch.

I like just having just integer. IMHO it is simply not worth the time
to try to figure out what is "major" in a project with so many
different uses.

So my vote goes to
* The bitcode compatibility promise is changed to use real time (at
least 5 years?) instead of revision numbers.
* The next release is 4.0.
* The next bugfix release is 4.1.
* After 6 months or so we release 5.0.

Cheers,
Rafael