ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ru...@us.ibm.com
Subject RE: nightly build (was: problem)
Date Sat, 24 Jun 2000 17:13:36 GMT


Conor MacNeill wrote:
> >
> > Since this is an all volunteer organization, everyone is empowered to
> > set one up themselves and publish it.
>
> OK, but most people looking for an updated build of ant come to
> jakarta.apache.org. They may not realise that ant is to be found under
> "Tomcat and Other subprojects". Certainly a number of posts here
> indicate that people are using the ant build that is part of Tomcat 3.1
> (modern compile problems, etc). Is there a process for changing the
> nightly builds done on jakarta.apache.org?

We are not terribly formal around here.

The nightly builds have been done by Costin on a Sun machine, and copied to
jakarta.apache.org.  The milestone and release builds have been done by me
on an IBM machine, and also copied to jakarta.apache.org.

First thing we should do is get a milestone posted ASAP.  I'll be glad to
do it, and believe that the Ant code is stable enough to be posted -
anybody object?  Or have any last-minute things that they really would like
to get into the next milestone?

We should also shoot for a "formal" release - I suggest early July.
Thoughts?

> > One difference of opinion I have with the nightly build process
> > mentioned above is that it fixes on a particular ant version for
> > the nightly build itself.
>
> It is cool to bootstrap ant itself for its nightly build. I don't know
> if it is necessary, however, to build all other projects with the latest
> version of ant. This couples all the projects together. Say we change
> ant to eliminate the ${} property syntax - we need to move all the other
> components to this new version of ant to restore the nightly builds. It
> puts the onus on ant to make sure all other projects still work when
> changes are made to ant. It may be better to let other projects fix on a
> version of ant and then decide when they want to upgrade to a later
> version.

A nightly build snapshot of Ant certainly shouldn't be used to create
formal milestones for other projects.

I'm not sure how I feel about whether nightly (i.e., experimental) versions
of other projects should use stable or experimental versions of each other.
In any case, I don't believe that there needs to be only one nightly build
of every project.  A build with stable versions of everything that your
project depends on certainly makes sense for problem isolation.

I started my effort because I was dismayed by the inability of current,
released versions of various Apache projects not working with the current,
released versions of other projects upon which they depend.  Not being able
to fix the past, I opted to focus on the future.  I figured that by
building nightly versions of various software projects together, I could
identify incompatibilities early.  Even early on, I was able to identify
changes to Cocoon, Xalan, Xerces, and Fop.  I'm continuing to expand my
scope, and just made recommendations to Castor, and committed an optional
XSL/T style task into Ant.

Note: none of this should imply that Ant developers need to make all the
changes to all projects.  I'm just providing a tool that will enable Ant
developers to assess the impact of any proposed change on others.  Care to
deprecate a feature?  Commit a change to issue a deprecation warning in
Ant.  The next day, scan the logs and take the initiative to contact the
owners of any project affected.  If the change is made for a good reason,
then they will undoubtably be appreciative of the early warning.

- Sam Ruby



Mime
View raw message