We just avoid that being an issue in three ways... 1) I slap anyone around who deploys a snapshot to a remote repository unless they have a _very_ good excuse. My method is to increment the major version if there is a breaking change and release early to avoid the need for snapshots. Ideally the repository would support sufficient metadata to tag releases as broken... but we get by for now.
2) enforcer plugin to stop releases having snapshots in them 3) all our versions are X.Y you only ever get X.Y.Z when you have patched a change to a library deployed into production On Tue, 08 Jan 2008 07:13:42 dhoffer wrote: > Which maven release/build is this in? > > Based on my understanding I don't think this is sufficient to resolve this > issue. It needs to exclude 1.0.4-SNAPSHOT as well, let me try to explain. > > If I specify a version range of [1.0,2.0) for a dependency, what I am > saying is that I will accept any RELEASED version from 1.0 (inclusive) to > 2.0 (exclusive). I am not saying I want any SNAPSHOTS to be allowed. The > only time a SNAPSHOT should be allowed is when it is specified by an > inclusive version range boundary. > > Michael McCallum-3 wrote: > > you can specify a range [1.0,1.1-!) which will stop 1.1-SNAPSHOT from > > being > > included, this wont stop 1.0.4-SNAPSHOT but i think thats valid anyway... > > > > On Sun, 06 Jan 2008 14:39:37 dhoffer wrote: > >> What is the status of this? This issue is very serious (highest > >> priority) > >> for us; every time we update maven we have to apply a patch to fix this > >> else releases fail. > >> > >> Can we come to some conclusion on how to fix this? > >> > >> -Dave > >> > >> mihobson wrote: > >> > Hi, > >> > > >> > Whilst attempting to fix MNG-2994, I discovered MNG-3092 that was > >> > contrary to the 2.0 design docs: > >> > > >> > http://jira.codehaus.org/browse/MNG-3092 > >> > > >> > Brett, Kenney and myself had a brief discussion on IRC about this: > >> > Kenney says that the behaviour is theoretically correct (which it is), > >> > although I feel it goes against the practical usage described in the > >> > docs. The two main choices I can see are: > >> > > >> > 1) We stick to the design docs and disallow snapshots in ranges when > >> > they aren't an explicit boundary, as per the MNG-3092 patch. > >> > > >> > 2) We reconsider the design docs and leave range resolution behaving > >> > as it is, then use profiles to enable or disable snapshot repositories > >> > at build time. > >> > > >> > Any thoughts? > >> > > >> > Mark > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > > Michael McCallum > > Enterprise Engineer > > mailto:[EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
