Daniel Rall wrote: > >> Here is a better example: Torque isn't released yet. So, all the versions >> say: torque-3.0-dev.jar. How do you know which version of 3-0-dev.jar is the >> right version? What if you need yesterdays version instead of today's? > > This is a serious problem. It can be addressed by either following > Jon's suggestion, or by not depending on CVS versions of JARs. > Perhaps Sam can comment on how realistic this latter option is?
In an ideal world, subprojects would only depend on released versions of one another. Unfortunately, life isn't always that simple. However, what I do all too often is cowboys picking up random snapshots and rushing to exploit the latest feature before it is released, and often getting burned as that feature is subject to change. It happens very frequently in Avalon land. One occurrence of it that I recall in this neck of the woods was Scarab picking up early copies of turbine-3. But I digress. What I would prefer is that before anybody standardizes on a non-released jar during the course of development, they make the development community for that code base aware of that decision and encourage them to mark that version of cvs with a tag. This tag need not have a meaningful name, and often the date would simply be sufficient. As these events are something that in my mind require careful deliberation and coordination, unlike Jon, I think that a granularity of a day would be sufficient. - Sam Ruby -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
