I think it's wise to limit the use of snapshots, even to the point where we say that it's not smart to publish your snapshots to a "public" location at all. This gets a little dicey with OSS projects, since the team is so widely distributed, but just saying that the snapshot repository is not supported might help out.
What I'm really getting at is that projects shouldn't depend on snapshots outside of their own development team (or that project, I guess is another way of saying it). The habit of publishing snapshots to a public location and telling everyone about them leads us away from milestone releases, which are the first thing that anyone in the project's user community should ever see. I'm interested to know which snapshots bit you guys so hard? Was it a [set of] internal snapshots, or were they snapshots from Maven or some other OSS project that you depend on or use? If we start talking seriously about shorter dev cycles and milestone releases with less of a barrier to release (for alpha quality, for instance)...and start shunning snapshots as an acceptable mechanism for distributing pre-release code...would that have helped you all? -john On 4/12/07, Kevin Menard <[EMAIL PROTECTED]> wrote:
I agree. I am suggesting that it's a little too easy to use SNAPSHOTs and that all that wonderful time maven was supposed to save you in preparing releases is trumped by the time it takes to just append -SNAPSHOT to a version number. Sure, it's people abusing it, but it's easy to abuse and looks like it's officially condoned as proper behavior. Things get even murkier when transitive dependencies are considered. So, I'm not suggesting dumping SNAPSHOT wholesale, but making it more difficult to distribute an artifact via SNAPSHOT (maybe require the end user to have to agree to use a new SNAPSHOT each time one is available or something). Maybe we'll just have to agree to disagree. I will say that this matter has bitten the Cayenne team a few times now, and we've come close to dumping maven altogether. It got to the point where we had to start pinning SNAPSHOTs by timestamp via a guess and check method. Perhaps the plugin Nigel suggested would help matters, though. -- Kevin > -----Original Message----- > From: Brian E. Fox [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 12, 2007 3:10 PM > To: Maven Developers List > Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 > > Snapshots are a very good thing for internal development. It > would be impossible to manage my builds without them. I think > that people using snapshots of plugins are a symptom of > another problem -- long release cycles. Just because people > do bad things with snapshots doesn't mean snapshots should go away. > > It already takes a little effort to get at them, the snapshot > repo isn't part of the super-pom, so if you go out of your > way to get them, you should understand the consequences. It's > like me picking up an unstable version of some jar and then > complaining that it broke later and asking the creators to > stop releasing unstable versions at all(that are clearly > marked as such). People would then just go get the code anyway. > > -----Original Message----- > From: Kevin Menard [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 12, 2007 1:09 PM > To: Maven Developers List > Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 > > Right. > > My point is that regardless of what the original intention > may have been, the current process facilitates laziness via > SNAPSHOTs. Without them, incremental builds would be > necessary, which would give fixed version numbers with known binaries. > > If the plan is to take actions to help prevent users from > having things break on them, this may be easier than the path > you outlined. > > -- > Kevin > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
