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