I agree with both perspectives though on balance I think I prefer using "-dev" in jar names. Using -dev in the jar name is a clear statement of intent - use the latest CVS HEAD build. So its ideal for sandbox stuff, or to use packages before their release. Maybe one day we can automatically update all the "-dev" jars ever night with the latest nightly build (kinda gump-style).
If a project is to do a release, then using the timestamp in the jar name is a nice way to do a pseudo-release of dependent projects; though we should always try and do real releases instead. James ----- Original Message ----- From: "St�phane MOR" <[EMAIL PROTECTED]> To: "Turbine Maven Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, May 28, 2002 12:32 AM Subject: Re: use of -dev in jar names > 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]> > _________________________________________________________ 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]>
