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: Preparing a Release
Date Tue, 24 Sep 2002 00:54:16 GMT
It looks like there are only two ant specific directives for the project. One 
is to update the component.version property, the other is the dist target. 
The later steps are for regenerating the jakarta site, and unless those steps 
are 'officially' changed, they should be done as documented.

Now, the question is, should the release be built with 'ant dist', or 'maven 
dist'. Ideally, that should be a distinction without a difference. If it 
isn't, I'd treat it as a showstopping bug. Rebuilding the source release with 
ant ought to reproduce the binary release. Ditto for the source release 
target in Maven vs the export from CVS. If you get something different, then 
it's likely you've got an irreproduceable build. 

The other thing to be sure of, is if your project has any dependencies, you 
need to build the release against the released version of the dependencies. 
If this is a problem, the unreleased dependency should be bundled with the 
release. And it's your nightmare to support it, not the guys who didn't 
release it. Better to push them to release. 

This is on point for CLI. Right now you depend on a random commons-lang 
snapshot. Fortunately, lang is heading for release. Then you can depend on 
lang 1.1. Unless you really mean that you depend on lang 1.0 or greater. In 
which case, you might want to actually build against 1.0.

Another issue can be what JDK version the release was built with. Earlier is 
generally better. That is, a JDK 1.2 built version will almost certainly run 
against any JDK, while a JDK 1.4 built version may not. There have been some 
API changes that affect backwards portablilty, like narrowing of signatures, 
not to mention some differences in bytecode. 

Yes, all of this stuff is paranoid and a bit anal retentive. But getting it 
right isn't that hard, and it's better than having all kinds of bug reports 
and hard to reproduce errors. 

"Release early and release often," is good practice for an application. For 
library code, it's a PITA for the clients of the library. Every release is a 
potential destabilization of the application. If the library changes too 
fast, it becomes a barrier to adoption. 

On Monday 23 September 2002 06:54 pm, John Keyes wrote:
> I should have looked at the commons index as well as the jakarta
> index ;)
>
> I've just done a brief scource of that document and I notice
> that all references are to use ant.  Should there be a separate
> page for maven based releases?
>
> -John K
>
> On Monday, Sep 23, 2002, at 21:43 Etc/GMT, Scott Sanders wrote:
> > The most relevant is:
> >
> > http://jakarta.apache.org/commons/releases.html
> >
> >> -----Original Message-----
> >> From: John Keyes [mailto:jbjk@mac.com]
> >> Sent: Monday, September 23, 2002 2:20 PM
> >> To: commons-dev
> >> Subject: Preparing a Release
> >>
> >>
> >> Hi all,
> >>
> >> I think the time is nearly prime for a CLI release.  I
> >> haven't found the page on Jakarta which states what is
> >> required for a release.  Can someone point me towards the
> >> required information.
> >>
> >> Many thanks,
> >> -John K
> >>
> >>
> >> --
> >> 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>


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