llvm dev - Jul 2004 - [LLVMdev] RE: LLVM 1.3 release discussion

On Thu, 15 Jul 2004 18:19:11 -0500 (CDT)
  Chris Lattner <sabre at nondot.org> wrote:
  
> This has no impact on the users at all... it has an impact on the
> maintainers of the LLVM .bc file reader. :)  The LLVM BC file reader has
> to have compatibility code to support loading of all released LLVM
> bytecode formats (1.0, 1.1, 1.2, etc).
Good point.
> 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. 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?

Reid.

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.

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://nondot.org/sabre/

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