commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <martin.coo...@tumbleweed.com>
Subject RE: [lang] 1.0 release foci (fwd)
Date Sun, 25 Aug 2002 01:15:49 GMT


> -----Original Message-----
> From: Steve Downey [mailto:steve.downey@netfolio.com]
> Sent: Saturday, August 24, 2002 5:09 PM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] 1.0 release foci (fwd)
> 
> 
> 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. 

Another way of handling this, without modifying build.xml, is to tag
everything for the release (with a regular non-branch tag), and then untag
the file(s) that are not intended to be part of the release. Then, when
someone (including the release manager) grabs LANG_1_0, they get exactly
what went into that release.

As with Daniel's proposal, a branch can later be created, if necessary, by
referencing the LANG_1_0 tag as the source of the branch.

--
Martin Cooper


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

The method suggested above would resolve both of these issues.

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


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