As I explained in response to your previous message, we already do that. You fixes were scheduled for, and always have been scheduled for 2.1.
2.1 has not been delayed in any way. 2.0.1 was pushed up with some bug fixes that were represented as more critical. As soon as the outstanding 2.1 bugs/features are completed, it will be released. If you now feel your bugfix is very critical, then it can be considered for backporting to the 2.0.x branch and a 2.0.2 release can be made. The lack of versions in JIRA back to 3 months ago limited our ability to do that. As for betas of plugins - that's definitely something we'd like to do but we don't have the repository separation setup right now. What we ask people to do is test snapshots instead. Perhaps a better idea is to push that to the users@ list for greater notice. When we have the announce@ list that will be different. - Brett jerome lacoste wrote: > Hi, > > I've had a little issue with regard to the latest release of maven > assembly plugin. Mostly because some issues I had reported and fixed > almost 3 months ago didn't make it into the release. > > So I am being told that 1- there was a description of the issues to be > fixed, and 2- there was a 72h vote. I don't deny that, but this is not > enough for me. > > First even though I've spent some time using maven or writing a couple > of plugins, I don't feel that I should intervene much on the dev list. > So I don't read it everyday. > > Second, maven introduced a new concept here: its plugins are released > on a case by case basis. This makes it very powerful, but makes us > having to be careful all the time. With all the other open source > programs I follow up, there's a traditional beta or rc release that I > can test and notify the developers when they missed one issue I cared > for (in particular if I've provided a patch). That doesn't work here. > And no, I can't read every single message on every single developer > list of all the projects I am using to be sure that my fixes make it > into the programs I use. > > When a milestone is about to be released, there should probably be a > way for us bug reporters to know. That's why I proposed to use Jira: > targeting an issue to a future release will notify me and I can react. > > So maybe you have a better solution, but clearly there needs to be > something to accommodate the life for those like me who cannot spend > their time going through 1000s of emails on 10s of mailing lists. > > Thanks for your understanding, > > Jerome, just trying to improve the process > > --------------------------------------------------------------------- > 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]
