ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <>
Subject Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/taskdefs
Date Fri, 02 Feb 2001 15:04:02 GMT
> > How do we fix the process so that items like this are noticed and
> > addressed earlier?
> Don't know, really. One of the problems with the tinderbox approach is
> that you always include experimental changes that may very well go
> away again.

Actually this is the strength of the gump system. If we add a feature, even
experimental, to Ant, it is nice to see it being used and tested in other
projects. We don't want to wait till we get to a release to have featured
used in anger. So, isn't one of gump's roles to be that early warning
system as those features evolve.

> My take on this is that every project that relies on alpha features of
> another project is responsible to track changes in that alpha version
> itself.

I think a released version of a project must only depend on released
versions of its prerequesite projects. By relying on an alpha feature of
another project, you are making your project alpha as well. That is OK, but
we should expect regular failures on gump.

> Well, this is easier to say than to do, I know. Especially
> when talking about projects that still don't have a single released
> version ...
> > Or that deprecated features are not removed until users who are
> > dependent on that feature have made the change?
> Using GUMP (is the capitalization correct?) to find users of
> deprecated features will help

It would be nice to have a single consolidated output of the whole gump
build to easily locate projects that are using deprecated features. We can
then help those projects to update. Also perhaps each project in gump
should have an attached mailing list which is notified of build failures in
the gump system. That sort of regular (push) reminder would help rather
than having to check the website (pull).

> but what about the projects the system
> doesn't track? I think there must always be an extended deprecation
> period before a feature can be removed - but it's kind of difficult to
> decide how long would be long enough.

View raw message