ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: What is going on in ANT1.x
Date Fri, 08 Feb 2002 04:34:51 GMT

----- Original Message -----
From: "Adam Murdoch" <>
To: "Ant Developers List" <>
Sent: Thursday, February 07, 2002 7:51 PM
Subject: RE: What is going on in ANT1.x

> > -----Original Message-----
> > From: Erik Hatcher []
> > Sent: Friday, 8 February 2002 12:53 PM
> > To: Ant Developers List
> > Subject: Re: What is going on in ANT1.x
> >
> >
> >
> > ----- Original Message -----
> > From: "Adam Murdoch" <>
> >
> > > If the <cc> task were to move across, is there some way we can
> > mark it as
> > > experimental, so that we can change stuff without worrying about
> > > backwards-compatibility (for the first little while, at least)?
> >
> > It should be automatically considered "experimental" until the release
> > Ant 1.5.  Nightly builds are considered unstable and "use at your
> > own risk".
> >
> > Just prior to the release of 1.5 we can reevaluate whether we want these
> > supported or not and either pull them or undocument them.  Seem
> > reasonable?
> >

I agree w/ erik about putting it in the main source tree, because it is
pretty thorough by the look of things. The only change I'd make was some way
of specifying env variables, especially our friend PATH. I have two version
of cl on my box now (vs6 and,  and would like control over which to
call. But that is the kind of tweak that use uncovers, so what we need now
is use, and that comes from putting it in the main CVS tree and giving it
regular stress.

> Yep.  I wonder if it might not be worth having an 'experimental tasks'
> section in the manual (particularly if we go with a 'deprecated tasks'
> section).  Then, we could *potentially* include experimental tasks in the
> release, so that people can try them out, but the disclaimer would be
> that they may change in a future release.

That is not a bad idea; we should put JSP in there now which is still pretty

> Too bad we don't have some way to attach meta-info to a task definition
> (like in an antlib descriptor, say).  Then, we could add 'deprecated' or
> 'experimental' flags to the task defs, and let the user explicitly decide
> whether to enable deprecated or experimental features (and have the
> container take care of it all, rather then the tasks).

Good idea about @ant:experimental metadata tags; another feature for antlib

> Of course, downloading a nightly build is a pretty explicit decision by
> user, so maybe the solution to experimental features is best left at that.

True, but I have also seen a lot of bugreps dealt with by saying "download
the nightly build"; some people may be forced to upgrade for bug fix
reasons, so they should see what is experimental.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message