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