[LLVMdev] 1 Week Before 2.0 Branch Creation

Tanya M. Lattner tonic at nondot.org
Sat May 5 15:48:14 PDT 2007

>> 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.

While its not necessarily a large functionality change, its probably too 
much to review with this notice. Chris would have final say on this, but 
in general its bit close to the deadline.

> > 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.
> In my experience, a code freeze lasts for a fair amount of time (on the
> order of months).  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.  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.

In my defense, there has been more than one email about the release 
schedule. In the future, I will send them out more often and also find a 
good place to put this on our webpage (I've been meaning to overhaul it, 
but havent had time).

> 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.

This is the case today. I verify on our  major platforms that there are no 
regressions from the previous release. Older releases may not have been as 
strict with this requirement (pre 1.7 I was not the release manager). 
Regressions should be fixed and we do delay the release if necessary.

> 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?

You should be aware of this:

Some of the process is not documented, but I always send emails about the 
next steps. You can look back in the mailing archives to see how we have 
done this is in the past.

Since this is my domain, I will draft something up. However, nothing will 
change for this release.


More information about the llvm-dev mailing list