directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [release] How are we all progressing
Date Tue, 14 Dec 2004 02:48:46 GMT
Noel J. Bergman wrote:

> One thought is this ...
> For a given Release, we decide which component(s) are going to be put out in
> a coordinated fashion for that Release.  This may not be all of the
> components, and components may be independently releasable, hence the
> separate {ttb} structures under them, but we are likely to do coordinated
> releases, as well.  An example would be that even though SEDA be be released
> separately, a given Release of Eve is going to be tested and built with a
> particular version of SEDA.
> Once we have decided upon the set of components, the Release Manager will
> setup a directory structure, possibly off the project root, to hold the
> components that will make up that particular coordinated release.  For each
> component, we may have a tag (marking the state of the component at the time
> we start the process) and a branch (marking the current state of that
> component).  For each component, development will continue in its {ttb}
> structure as normal.  The Release Manager will decide what to merge from the
> component development tree into the release branch.  No one else will merge
> into the release structure.  At the point where the release happens, the
> release branch can be copied back to the development tree's tags/ directory
> as a marker.
> That's a strawman.  Feel free to modify.

Sounds great conceptually and I get what you mean about leveraging svn 
to do things in a better way. I also like the idea of coordinating 
component releases.  I have a couple of practical questions / comments:

1. What do we vote on?  Seems we would need minimally two votes:
a. plan for components and composition of release
b. coordinated release candidate
Do we also need to vote on individual components?

2. Do we version and document the coordinated release -- i.e., assign a 
release number to it, release notes, etc; or do we just version the 
components?  Obviously independently releasable components will need 
full release notes, docs, distributions and and their own version 
numbers. The question is what status does the "release bundle" have? 
What version numbering scheme will we use?

3. After the release contents have been decided, development can 
continue on the components. Assuming that there are dependencies among 
the components, how do we make sure that the RM can always effectively 
decide what to merge in? This is not well-stated, but the "build A 
against a non-released tagged version of B" approach can lead to some 
nasty dilemmas (usually along the lines of the bug fix really required 
to make the tagged B releasable depends on an incompatible change 
introduced later). One way around this is to freeze the APIs of 
components that others depend on when the release contents are determined.

4. I like the idea of one RM driving the coordinated release. This could 
be a real time-saver both for us and users. Even at this stage, however, 
this job will require a significant amount of help from the component 
teams. This will probably take care of itself informally, but we might 
want to consider asking someone to step up for each component to develop 
and execute the release plan for that component.  I will gladly 
volunteer to do this for [naming] this time.

I am sure we will learn a lot in the initial release and we can iron out 
all of the details as we get through it. The main reason that I 
suggested earlier that we borrow from other apache projects was to 
expeditiously settle the policy questions; but I agree with you now that 
it makes sense to reexamine the whole process using svn and the bundling 
idea that you have above.  This is going to be fun :-)


> 	--- Noel

View raw message