[LLVMdev] RE: LLVM 1.3 release discussion

John Criswell criswell at cs.uiuc.edu
Fri Jul 16 06:57:29 PDT 2004


Chris Lattner wrote:
> On Thu, 15 Jul 2004, Reid Spencer wrote:
> 
>>>There is always a tension between releasing too frequently (so people
>>>never bother to run the latest and greatest) or releasing too slowly (CVS
>>>drifts too much from the latest release).  I agree that a release every 3
>>>months seems best.
>>
>>On the other hand, I also believe that each release should be targeted
>>towards some scope. The devs should get together at the start of a release
>>cycle, sign up for what they'll do in the next 3 months, and a (loose) plan
>>should be set for the next release. Having an objective for the release is
>>important to keep it on focus.
> 
> 
> Hrm, I don't know if this is really possible in a loosely organized
> open-source project.  Everyone sorta works on what interests them, and it
> gets integrated into the tree.  There isn't a big driver saying that this
> and that feature will be implemented: it's whatever people are interested
> in.
> 
> 
>>If it all gets done in 2 months, fine,
>>release early. If it isn't done in 3 months, either cut scope (back out
>>changes) or decide to extend .. but never beyond 4 months. Of course, there
>>should always be wiggle room for new ideas, contributed patches, etc. The
>>release target should be just a guideline of the major new functionality and
>>bug fixes to be addressed. Sound reasonable?
> 
> 
> This isn't really how we work.  Due to the nature of how LLVM is
> developed, mainline CVS is ALWAYS stable.  There may be minor transient
> bugs that go in, but we don't have "periods of instability".  This is
> primarily due to the incremental nature of our development.
> 
> Because of this, we can basically release whenever we want, controlled by
> testing packaging and end-user pains.

Just to give people an idea of what we do to make a release:

1) Mark the LLVM tree and create a release branch.
2) Create the LLVM tarball.  Build it on Linux, Solaris, and MacOS X.
3) Build the CFE (Linux, Solaris, and MacOS X):
	a) Compile and install the CFE
	b) Remove Solaris and MacOS X header files that were "fixed" by the GCC 
install process.
	c) Build the LLVM runtime libraries and install them into the GCC 
directory.
	d) Get them all arranged correctly and create the tarball.
4) Run the test suite on Linux, Solaris, and MacOS X.
5) Optionally, compile other programs with LLVM to see how well it is 
doing.  We slowly integrate these into llvm/test/Programs, but it takes 
time.
6) Re-do Steps 2-5 as bugs are fixed or documentation is changed.
7) Put the files on the website.
8) Test downloading from the website and installing LLVM.
9) Tada!  Release.
10) Fold any changes from the release branch back into the mainline CVS 
trunk.

While it is true that CVS mainline is always stable, it sometimes 
develops bugs on platforms that we don't use as frequently (e.g. 
Solaris).  Some of these are found during the release cycle, as that is 
the time when we put LLVM through its paces on all of the supported 
platforms.  So, Step 6 usually happens at least once.

In my experience, this process takes at least a week.

> 
> -Chris
> 

-- John T.

-- 
*********************************************************************
* John T. Criswell                         Email: criswell at uiuc.edu *
* Research Programmer                                               *
* University of Illinois at Urbana-Champaign                        *
*                                                                   *
* "It's today!" said Piglet. "My favorite day," said Pooh.          *
*********************************************************************





More information about the llvm-dev mailing list