[LLVMdev] 1 Week Before 2.0 Branch Creation
sabre at nondot.org
Sat May 5 14:34:32 PDT 2007
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
> > 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:
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
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
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
> 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.
More information about the llvm-dev