"...but anything that i share with other developers has a release version. Each of our artifacts that in active development will get released at least once a day."
That strikes me as working against the grain of agile development. Our developers work across components and need to link in that new component build right now, not next day 'when the other department makes that change and makes the daily release'. We want to be continually refactoring code and often we find we need to move some application logic into a shared component. We want to do that now and let all developers get that change now. (And I don't want to be forced to making a release each time, we often do if we are done, but this should be flexable.) "...the main reason being that i should not go messing with other developers environments unless I am confident that all the tests pass and the code works the same or better than before. " I don't disagree, all tests pass just the same it doesn't matter if its a snapshot or release. Maven is designed so developers can link with either snapshots and/or releases it should not matter. "...I want a tool than gives me the power to define exactly what I am deploying and allow me to easily develop that and patch it if necessary. We are working with over 11 projects composed of 130 or so artifacts. It all works very well without snapshots being deployed. We do of course make use of snapshots in our local repositories though." Here too I don't disagree, snapshots are not supposed to be released and we would never do so. We only release releases, the release-plugin enforces this anyway. I don't disagree that you can't do what you say...I'm just saying that you should not HAVE to make as fine grained of releases as you do so that version ranges work. IMHO, your work-around degrades releases to less than they should be. Not only is a release a time consuming task, it generates reports, sites, etc. I want developers to know they can trust and rely on these releases with the corresponding documentation. It would be quite a nightmare if instead of the 100 minor releases I have now I have 10000 minor releases and have to keep track of good vs. bad ones, etc. "...Once of my major beefs about snapshots being deployed is that you get to a point where you want to make Release and have to unroll and whole tangle of transitive snapshots. We make at least one Release everyday and really need a fully consistent ready to deploy tree of artifacts." We use snapshots and don't have to unroll anything. We simply go about making the release of the snapshot. All regular projects use version ranges to automatically get that new release. The one project that was using that snapshot now gets updated to remove the reference to a snapshot (back to full version range). "...We mark the completion of a task as the release of the artifact... so if you have developers willy nilly deploying snapshots as a single developer i cannot easily mark the end of my work without rolling up other peoples as well. The simplest solution is to require by process that people release things regularly. And use metadata - or otherwise -to manage horribly broken artifacts, which very rarely happen with decent tests." At the end of a task, we too release the artifact; else you really aren't done! I guess the big difference is that I don't need any metadata...I let maven do it all. Releases are just that known good releases and snapshots are everything else...they just go away when not needed anymore. "...In any case My vote would be for maintaining the current behaviour and allowing an option to change it at runtime or on the command line. You run the risk of breaking builds otherwise." I don't know what you mean by "option to change it at runtime or on the command line". Yes if there is a way to optionally get either behavior I would like to discuss this. However I don't see why your vote would be to maintain the current behavior. You don't use snapshots anyway so what does it matter to you? I do and with them version ranges is broken, lets fix it and we both get what we want. I don't understand the last statement 'You run the risk of breaking builds otherwise.' Michael McCallum-3 wrote: > > On Tue, 08 Jan 2008 14:25:06 dhoffer wrote: >> 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. >> > Perhaps the implementor realised the spec wasn't right and failed to > update > the docs... > > Anyway to snapshots, well the pom thats in the trunk of any artifact has a > snapshot version but anything that i share with other developers has a > release version. Each of our artifacts that in active development will get > released at least once a day. The main reason being that i should not go > messing with other developers environments unless I am confident that all > the > tests pass and the code works the same or better than before. > > I want a tool than gives me the power to define exactly what I am > deploying > and allow me to easily develop that and patch it if necessary. We are > working > with over 11 projects composed of 130 or so artifacts. It all works very > well > without snapshots being deployed. We do of course make use of snapshots in > our local repositories though. > > Once of my major beefs about snapshots being deployed is that you get to a > point where you want to make Release and have to unroll and whole tangle > of > transitive snapshots. We make at least one Release everyday and really > need a > fully consistent ready to deploy tree of artifacts. > > We mark the completion of a task as the release of the artifact... so if > you > have developers willy nilly deploying snapshots as a single developer i > cannot easily mark the end of my work without rolling up other peoples as > well. The simplest solution is to require by process that people release > things regularly. And use metadata - or otherwise -to manage horribly > broken > artifacts, which very rarely happen with decent tests. > > Consider one of my least favourite quotes "But it worked yesterday!" > > For stable artifacts the rate of commits/checkin to releases is close to > 1:1. > For developing artifacts its much higher. > > In any case My vote would be for maintaining the current behaviour and > allowing an option to change it at runtime or on the command line. You run > the risk of breaking builds otherwise. > > -- > 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-tp11464715s177p14681397.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]
