commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Downey <steve.dow...@netfolio.com>
Subject Re: [lang] 1.0 release foci (fwd)
Date Sun, 25 Aug 2002 00:09:17 GMT
It depends. Right now we're faced with one class that has to be removed before 
the release can be cut. And with the OS detection discussions, we'll probably 
have more.

I assume by changing build.xml, you mean to exclude certain classes from the 
compile, javadoc and copy source targets. I see a couple of problems. First 
is that the changes only apply if you're working on the release. So you have 
an implicit branch there already. Second is that it's non-obvious to the 
casual observer. There's source in there that doesn't show up. It's hard to 
build the library correctly from cvs checkout without using ant. 

I'm not saying that's a 'hard' requirement. Certainly Tomcat can't be built 
entirely correctly without ant. But it's a nice to have if the library can be 
built with a tool like Eclipse or Netbeans. 

A stronger requirement is that the build can be reproduced from source. That 
means
cvs co -r JAKARTA_COMMONS_LANG_REL_1 jakarta-commons/lang
cd jakarta-commons/lang
ant dist

gets you exactly what ends up being distributed.

How you arrive at this point is really up to the release manager. I tend to 
like a full beta-rc-release cycle, and it's easier to control what's 
happening on the release branch, as opposed to HEAD. 

For critical projects, once it's in RC, I've even gone to review-commit, 
rather than the normal commit-review, asking that all patches go through the 
release manager. That's a much easier sell on a branch, since it doesn't get 
in the way of ongoing work. 

Release management and configuration management isn't an exact science. While 
there are definitely wrong answers ("ship whatever's on Bob's computer on 
Tuesday"), there are a lot of right answers. It's a matter of tradeoffs and 
what works.

Consistency, though, has a large value. If a practice is necessary for some 
project, it's good to apply it to all projects. That way you know how to do 
it when it is necessary. It's been internalized. 

The general release engineering practices are pretty high to begin with at 
Jakarta. We take source control for granted, for example. GCC didn't adopt 
source control until somewhere around release 2. But the practice of just 
cutting a release by marking the HEAD branch can lead to some very sloppy 
releases. Most of the time it works fine.

BTW, I'm advocating a branch not because I expect the differences between 
releases to be large. I'm advocating a branch because development velocity is 
high. I'd like to see the velocity maintained, while still making sure that 
the release that is finally cut is stable and tested.

If you find a bug in release 1.0, and there are substantive changes in HEAD, 
then you don't have an option. Even if HEAD is releaseable, you need to 
supply the bugfix to clients using 1.0. Expecting them to upgrade at your 
convience is foolish. If there are substantive changes, they need to go 
through their whole release cycle. They need something that can be dropped 
into place without code changes on their side.



On Saturday 24 August 2002 03:53 pm, Daniel Rall wrote:
> Branching is definitely good practice when the differences between
> releases are medium to large, but [lang] has not yet reached that
> point.  The trade-off between a small change or two to the build.xml
> and the overhead associated with branching and porting rather heavily
> favors the former.  A simple tag can be turned into a branch point at
> a later date if it later becomes necessary to backport changes from
> HEAD to cut bug fix version of a previous release.
>
> For instance, we release [lang] 1.0.  HEAD changes radically.  A
> problem is found in released code from version 1.0.  We fix the broken
> code in HEAD, but it is still not at a release point.  We then
> exercise our option of turning the LANG_1_0 tag into a branch point.
> The fix from HEAD is backported into the LANG_1_0_BRANCH, and version
> 1.0.1 can be tagged and cut from that branch.
>
>
> ---.--------- HEAD -------->
>     \
>    LANG_1_0
>       \
>      LANG_1_0_BRANCH
>         \
>        LANG_1_0_1
>           \
>            `--->
>
> Using this standard technique, we avoid the (very real) overhead of a
> branch until we actually need it.



--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message