> From: Russell Gold [mailto:[EMAIL PROTECTED] > On the other hand, perhaps the special version "LATEST" should > override that behavior and say that the task should try to pick > whatever version is the latest, and compare its times. This is more > common in at least some styles of internal development, where version > numbers don't make as much sense.
This is something that we use heavily for internal development. With the twist that we have several LATEST, one per release target, usually corresponding to the given CVS branch. We use a 'tag' and a 'label' to identify such dependencies, and often have label=latest until we reach stabilization were label gets fixed to a given version; but most often the tag is explicit and several are available to choose from. I'm just throwing this out as a possible use case. We have a home grown system that does that, which <dependencies> will hopefully make obsolete ;-) (or in fact complement, as our system does not download Jars, but a zip of JARs, Native libs, runtime descriptors, etc... and we could use a simpler model for simpler pure Java jars). --DD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
