Regarding 1: Well that's not normal maven operation. You apparently have created a 'work-around' that works for you...I prefer to fix the bug so it works as it is specified.
There are lots of reasons to deploy snapshots. Normal maven behavior is that everything, in development, is always a snapshot. You have to deploy these so they can be used by others; now we do keep these on a separate repo, never mixed with releases. I agree with incrementing major version for breaking change. However this does not eliminate the need for snapshots. Not every check-in should be a release! Releases should be when you estimate you have enough 'correct' checkins to warrant a release. It sounds like you may not be using snapshots with version ranges simply because of this bug!?! BTW, because of the rule that only major version changes should break the API; this is why we really want/need to use version ranges. I.e. we always want builds to get the later versions. I would say that releases should never be broken; once you make a release you are committed to it! As you say, you can make a X.Y.Z release if you find a bug. Furthermore you cannot solve this problem by saying you don't deploy snapshots to remote repos. If you have one in your local repo you have the same problem. There is no mechanism to prevent usage of your local repo! Regarding 2: I have no idea what the enforcer plugin is, I will check it out. Again I should not be forced into a 'work-around'. For instance, it's not just releases that are a problem. When I run the idea plugin, for instance, I don't want it to include snapshots either. All this would work if version ranges worked as specified. Regarding 3: I concur. Michael McCallum-3 wrote: > > 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] > > > -- View this message in context: http://www.nabble.com/Version-ranges-and-snapshots-tp11464715s177p14680482.html Sent from the Maven Developers mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
