[cfe-dev] LLVM 2.6 release schedule

[Chris Lattner]

On Jun 16, 2009, at 1:35 PM, Eli Friedman wrote:

> On Tue, Jun 16, 2009 at 10:57 AM, Tanya Lattner<lattner at apple.com>  
> wrote:
>> Hello! I posted this to llvmdev, but because 2.6 will be the first
>> release including Clang, I thought I should also announce it here.
>
> At this point, it's probably worth discusssing what we actually want
> to do for a release.

Sounds good, just MHO:

> What's the version number?  Are we going to call it clang 2.6, clang
> 1.0, clang 0.9, or something else?  Are we going to call it a preview
> release, or do we think it's stable?

I think we should call it 1.0 or 2.6.  I consider Clang to be quite  
stable for C/ObjC, but not perfect.  Calling it a 1.0 release sends  
the right message, but calling it 2.6 would also make sense to me.

> What sort of release validation should we do?  At a minimum, I think
> we want to make sure clang builds and "make test" passes on all the
> platforms where we do release validation for LLVM.  PR4171 is blocking
> this.  Beyond that, it would be nice if the C tests in llvm-test
> passed on x86-32/64.  Anything else I'm missing?

Our official policy for llvm.org releases is more about regressions  
than quality.  As clang hackers we want to make it as good as  
possible, but the first release is about setting a baseline.

> We really need to make sure all of our documentation is in shape;
> being the first LLVM release with clang, it's probably going to
> attract a significant amount of attention.  The documentation is
> mostly in reasonably good shape at the moment, but the users manual in
> particular needs work.  Updated performance numbers would also be
> nice; the numbers at http://clang.llvm.org/performance.html are pretty
> old.

Yes they are.  Daniel, can you please update the perf numbers?  I can  
send you my slides if you want.

> Are there any particular features/bugfixes that we should try to make
> sure are in the release?  From the perspective of "we don't want to
> accept code that gcc accepts, but compile it wrong", PR2461, PR3679,
> PR3811, PR3895, PR4098, and PR4386 are of interest.  We should also
> try to figure out the issues with unreduced known miscompiles,
> specifically PR3480 and PR3910.  PR4296 and at least parsing for
> PR3429 would be nice because the errors are confusing.  (List of all
> those bugs: http://llvm.org/bugs/buglist.cgi?quicksearch=2461%2C4010%2C3679%2C3811%2C3895%2C4098%2C4386%2C3480%2C3910%2C4296%2C3429
> )

I think we should aim to fix as many of these as possible, but that if  
the release comes up and we haven't fixed them all that we should ship  
anyway with LLVM 2.6 anyway.

-Chris