Brett, I can see some logic to this as it's just another shade of grey between the current snapshot repo and central. It does however feel a little like a hack to work around some version ranging issues. I think massembly is a good example of where this is needed, but perhaps mdep is a case where it's not. This is still in "alpha" because there are more goals planned to be added. While the plugin overall is alpha, some of the original goals (copy/unpack, etc) are quite mature and very stable. If we did this, it would raise the bar a little higher for people to get useful functionality.
I think as mentioned in the assembly thread, that perhaps RELEASE isn't what we need. Maybe we break that down into STABLE / UNSTABLE and if there is no existing stable version, it would grab the latest unstable one (essentially solving both massembly by getting 2.1 and mdep by getting the newest until it is stable) As for plugins that are bound in poms, I think the best practice should be to use pluginManagement. It's the only way to guarantee reproducibility and consistency across an organization. Every plugin I use in my corp build is controlled this way and I really have no issues with it. (Slightly off topic, but related to my previous statement) The only thing that is slightly annoying is when you have plugins with goals that are both meant to be bound and some for the CLI. When you put a plugin in to pluginManagement, this applies even to the CLI versions. I'm not sure if/how we could make this better but here's the use case: I use mdep to unpack and copy stuff so I set 2.0-alpha-3 (example). But now I want to prepare for 2.0.6 and want to run dependency:analyze and I want 2.0-alpha-4, I have to change my pluginManagement. I guess a way to override PMgt from the CLI would be sufficient here. --Brian -----Original Message----- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 28, 2007 7:46 PM To: Maven Developers List Subject: [discuss] Splitting the stable and unstable repositories Hi, I didn't want to pin the assembly plugin vote to this, but it seemed like a good opportunity to bring this up. I'd like to propose we split the stable repository from the unstable repository (which would be where alphas, betas and rcs get deployed), and make this a documented best practice. This would not be a concept change in Maven (at least, yet - it could be something to consider in the versioning in future): it's simply two types of release repositories. The stable one would be included in Maven by default, the unstable/pre-release one would not. You'd have to add the repository to your project. I would suggest this for future additions to central, but leave anything currently there in place for backwards compat. I think this is a good all round concept, but there is a particular practical problem that we should do this for: unpinned plugin versions. In the specific example of the assembly plugin - if you don't request a version (ie, use latest release), or you said [2.1,), then you'll get the 2.2-beta-1 release which is presumably less stable than 2.1. The same rationalisation would apply to ranges used in any dependency, but thats the biggest use case I can think of that affects people today. It would allow us to do more regular test releases of the plugins. Thoughts? - Brett --------------------------------------------------------------------- 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]
