[llvm-dev] [cfe-dev] [3.9 Release] Release plan and call for testers
Renato Golin via llvm-dev
llvm-dev at lists.llvm.org
Mon Jun 13 09:54:44 PDT 2016
On 13 June 2016 at 17:24, Robinson, Paul via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> I don't know that the actual policy has ever been formally documented,
> although it has been discussed from time to time, so it's not too
> surprising that people have different ideas of what the policy is.
There isn't one. Never was. The *big* changes from 1.x to 2.x and 2.x
to 3.x were coincidental at best. There was no effort to hold features
until "the next big release comes out", like GCC.
However, I do want us to change to follow what almost all other OSS
projects do, so writing it as a policy now may discourage that change
and give folks some comfort that their idea has merits.
I fundamentally agree with David that we have a poor way of naming
releases, and that messes up a lot of infrastructure out there.
But we do have one policy, which is to warn of any potentially
damaging change with *at least* one release in advance.
Until now, we always moved from x.9 to (x+1).0. Not because it was a
rule or was written somewhere, but because we did. So, doing it again
will yield no surprise. If, OTOH, we create a 3.10, it will be our
first two-digit release, and that may, actually, break stuff
downstream.
So, my proposal on IRC was the following:
1. Get over it, call it 4.0 and release 3.9 as scheduled.
2. *Just after* the release, start the discussion for 5.0
This way we'll have at least 5 years to get it right, and people will
know (we can document that) that changes are coming. But we can also
change from (ex) 4.3 to 5.0 as soon as we agree that we'll do that.
My point for the delay is two-fold:
1. Changing the number is not just about naming, it's about behaviour.
We'll be telling the world that Clang/LLVM 3.x should work with *any*
3.x components, which is *not* true today.
2. We'll give time for people to agree or disagree, before we name the
release on SVN. People release Git-versions of LLVM and call them
"llvm-3.9-git". Imagine if we create "llvm-3.10-git" but we decide to
change later on to 4.0?
So, let's discuss about code freeze, feature branches, stable
releases, etc, *first*. But for that, it'd be good to get the SVN vs.
Git out of the way even sooner, so, we're talking years, here...
cheers,
--renato
More information about the llvm-dev
mailing list