[LLVMdev] 1 Week Before 2.0 Branch Creation

[Chris Lattner]

On Sat, 5 May 2007, David Greene wrote:
> Tanya M. Lattner wrote:
>> How large of a change have you made? With 3 days before the branch
>> creation, I strongly advise people not to be checking in major changes.
> Depends how you look at it.  Structurally, it separates two files into
> four and moves some functionality from one class to a new class, so in a
> sense that's a big change.  Code-logic-wise, it does nothing at all.  I
> will send the patch to the commits list today.  Hopefully someone can
> look at it and decide whether to apply it.

This sounds like great stuff, and is definitely progress towards a better 
RA.  However, it doesn't provide any user-visible feature, so I think it 
makes sense to apply this immediately after 2.0 branches, just to reduce 
risk.

> > We may need to change our proceedures for releases in the future.
> > This is how we have done it in the past with no problem, but LLVM is
> > growing much more rapidly now.

> The way I've seen it done in many projects is that
> there's a deadline to get all new feature work in (with more than a
> week's notice!).  Then the new branch is created.

To be fair, this has been the plan for quite some time:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-March/008322.html

We should probably find a way to publicize this better on the web page. 
As an aside, the web page definitely needs a major overhaul :)

> In my experience, a code freeze lasts for a fair amount of time (on the 
> order of months). The next two or three months, only bugfixes are 
> allowed on the release branch.  Some projects close the development 
> branch to force bugs to be fixed first, while others run two branches in 
> parallel.  I would lean toward the latter and trust people to be 
> responsible enough to fix bugs before release.

Right, this is a very common approach, used by many projects.

For LLVM, we have traditionally taken a different approach: keep mainline 
as stable as possible at all times, then make the release branch a short 
cycle that only accepts *critical* bug fixes (even things like 
miscompilations or compile crashes aren't taken if they are at all risky).

The idea is that we always keep mainline CVS close to release quality. 
This is good for everyone doing daily development of course.  In practice, 
minor regressions occasionally slip in during the development cycle, so 
the tree isn't *always* happy.  However, these problems are usually 
"shallow" problems that are easily fixed, they don't require major new 
rearchitecture, etc.

One major difference between LLVM and some other projects is that we 
usually promptly fix incoming bug reports (particularly regressions) as 
they happen, on mainline.  There is no need to wait for a release branch 
for this.

In general, branches are an extremely expensive way to spend human time. 
I prefer to keep branches (release and otherwise) as minimal and 
short-lived as possible.  This is one reason that we almost never use 
branches for mainline development, even for large projects: we find a way 
to break the project down into incremental pieces, which are independently 
easy to test and are less scary than the big rewrite :)

> The release is done when there are no new regressions and all tests
> created for new features pass.  Of course, this means that folks
> should be creating tests for their features.

Absolutely.  We definitely do this today.  In general, I think that the 
LLVM project has done an excellent job of making each release 
monotonically better than the previous one.  LLVM 2.0 has been used to 
compile *large* quanitites of source code.  While it contains a large 
number of new features, I am quite confident it will be our best release 
yet.

> Do we want some kind of discussion about what this process should be
> followed by a formal proposal drafted by a few people for comment and
> possible adoption?

Sure, I think that makes sense.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/