Stephen Haberman wrote: >I like the standardized naming of most of the Jakarta jars: >log4j-1.1.3.jar, velocity-1.3-rc1.jar, and the like. > >What I don't like is using -dev in the filenames. I could be wrong, but >my guess is that this means the latest snapshot of the CVS tree, e.g. >turbine-3.0-dev.jar. > >The problem is that while released versions, be they beta or rc or what, >are hard targets. The -dev doesn't really mean anything; it can change >from day to day depending on whenever a project's developer happened to >create it. > >This wouldn't really matter if all projects had their own lib dir, but >with Maven's very cool lib.repo approach, I would think the -dev could >easily start messing up things between projects. > >Instead, I'd suggest that any pre-release (non-beta/non-rc) jars be >named with the date of the CVS snapshot instead of just dev. E.g. >turbine-3.0-20020527.jar. > >Thanks, >Stephen > Well, I think it's a matter of what *strategy* you choose.
IMO, the decision to take is between : - using a stable release - using the latest available code In a single project / single lib dir environnement, if I choose the dev approach, I prefer to use the "-dev". Otherwise, to me, it would mean using a "latest-but-not-latest" lib, which is a bad idea, IMO, as the latest code is *generally* better than the older one. The problem is different in a multi-project / single lib repo environnement, of course, because a change in one lib would mean to have to change ALL projects. BUT, this could result in having tens of libs ~= the same. Eg: turbine-3.0-20020527, turbine-3.0-20020101, turbine-3.0-20010203, etc... This would fill up the lib.repo at light's speed, and would make it really confusing, never knowing which one to use. This problem grows exponentially with the number of dependencies. IMO, the single lib repo approach forces the developper to choose between one of both approaches : stable release OR cvs snapshot. If you have enough developpers to work on all your projects in the same time, and if you want to use an evolving code, then you choose the "-dev", so that all coders adapt in the same time to the same lib, keeping easy the integration (two projects don't rely on different APIs). If you don't, then you choose a stable release, and you don't have to bother anymore on which snapshot to use. To make it short, I would vote -1 to using timestamps in a multi-projects / single lib repo environnement. My 2 cents, St�phane _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
