> Others can run builds with stable dependencies. They are permitted, and
> even encouraged to do so using Gump. The runs I have been making are to
> determine the impact of changes - something that I think that has not
> received enough attention, and so that's why I have been and will continue
> to focus the runs that I make on that.
That's a valid configuration, I'm not saying to drop it - I just want to
be sure that both "styles" are supported. My interest is in using gump for
tomcat3.x builds - maintaining the scripts for testing is enough effort,
if I can use gump for building I'll save time.
The tomcat nightly should include the latest tomcat and the stable
dependencies - whenever it'll be released, it can't depend on the
"latest" ant but on the "latest release".
> Since you gave the specific example of ant, I do not like the idea of
> ant-1.3 being released without some assessment of the impact of changes on
> other projects. There was a change that would have gone into 1.3 that
True - I will probably start using/testing ant-1.3, since it'll probably
be released before tc3.3.
> Given the number of projects we have here, each project binding too closely
> to exactly one version of each of their prereqs means that someone who
> desires to compose a system out of these components is likely to run into
Assuming an change happens in ant-1.3 ( or ant-1.4 or 2.0 ), should
tomcat/xalan/etc be updated to use the latest ant or the stable ant ?
Yes, in theory all API/DTD changes should be backward compatible - but in
reality we are talking about projects that are in development mode, not
about "standard" APIs. And if a project has a dependency on another
project, it is expected to track the changes ( and we did changed the
build.xml several times already ), but with certain granularity.
IMHO relaxing the requirement to "latest released version" is a very good
idea. Maybe when a project enters "feature freeze" or "beta" we can update
the builds and make sure all other projects work with the freezed
APIs/DTDs, and roll back/fix what is broken.
> problems. So, in fact, I would be greatly pleased if there were multiple
> nightly builds going on out there with different combinations. And
A tomcat3.x nightly build will happen soon.
> Making ant build.xml files as a target of gump would be a valuable
> addition. It has been often discussed, but never contributed.
> Getting using http as an alternative to cvs would also make a great
> addition.
My time is as limited as anyone else, but I'll try to do at least (1).
( if you remember the nightly builds of tomcat used to be ant-based
and used to use get, so most of the code is there, it just need to be
geenralized to gump )
> P.S. What does it mean to have gump "working", but not
> "updating/building"?
It means: spell error, I meant "is no_w_ updating" (instead of "not").
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
