Hi Eric, The aditional work to deploy a snapshot of your plugin is very small. Just maven plugin:repository-deploy -Dmaven.repo.list=apachecvs This way users can get a snapshot before a release without the effort of building from cvs and see if it has any bug. But first http://jira.codehaus.org/browse/MPPLUGIN-26 should be fixed, I'd like to see any comments on my patch.
Regards Carlos Sanchez A Coru�a, Spain Oness Project http://oness.sourceforge.net > -----Original Message----- > From: Eric Pugh [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 12, 2004 12:58 AM > To: Maven Users List > Subject: RE: Plugin release procedure, was Re: Dashboard > plugin release status? > > I like the idea, however I can see this as being too much > work. As someone faced (admittedly doing it the first time) > with releasing some plugins, I feel like this is too much. > > What is really needed is more extensive unit testing of > plugins. For instance, with the CruiseControl plugin, I have > added unit tests that verify that the SCM plugin works the > way I expect it to work. This has helped me > catch issues when SCM has changed. More unit tests will > help the stability > of plugins. Additionally, I have my email set up to flag me > when a CVS commit message is about a specific plugin that I'm > interested in. > > The idea of a release period is nice, but with the amount of > manpower available, I'm just happy to see a plugin released > at all. I called a vote to get my plugins released three > days ago, and haven't (for various reasons) managed it yet.. > So I don't see the level of organization arising to get every > plugin to hit a specific period. > > On a related note, I am assuming you are hoping to reduce > churn in your plugins? I have been working on a plugin that > checks for newer versions of your current plugins and/or > project dependencies. The idea being that you can quickly > pull all the update information versus manually checking it. > I can share this with you if you like. It's still a work in > progress however. > > Eric > > > -----Original Message----- > > From: Paul Spencer [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, August 11, 2004 10:25 AM > > To: Maven Users List > > Subject: Plugin release procedure, was Re: Dashboard plugin release > > status? > > > > > > In an effort to balance "access to updated plugins", > "quality of the > > released plugins", "user expectations", and "developer > resources", I > > purpose the following procedure whenever a plugin has been updated. > > > > 1) Deploy a snapshot of the plugin. This allows the > community access > > to the updated plugin and provide feedback prior to an > actual release. > > > > 2) Update the plugin's website, i.e. site:deploy. This will notify > > the community that the plugin has been updated. > Additionally posting > > a "Snapshot Announcement" to the user mail list would be an nice > > enhancement to this procedure. > > > > 3) Assuming the plugin works, release the plugin during the next > > "Release Period". This will ensure the quality of all plugins by > > allowing the community time to provide feedback on updated plugins > > while minimizing the amount of time spent on integrated testing. > > > > "Snapshot Announcement" - An announcement, similar to the release > > announcement, but for a snapshot. The announcement should include: > > o List of changes > > o Download instructions > > o Anticipated release date/period > > > > "Release Period" - A set period, i.e. the first week of the month, > > when all unrelease and working plugins are release. During > this period: > > o Each unrelease plugin must pass all of it's testing. > > o All plugins must be retested, i.e. integrated testing. This is to > > verify dependent plugins work. As an example the SCM > plugin depends > > on the CHANGES plugin, so changes to the CHANGES plugin > will affect > > the SCM plugin. > > > > Paul Spencer > > > > > > Brett Porter wrote: > > > > > We weren't talking about bugs. We were talking about new features. > > > > > > > > >>So you'd rather not release early and often? That has > nothing to do > > >>with fixing bugs. > > > > > > > > > But it has everything to do with not introducing new ones. > > > > > > > > >>What if there are bugs fixed in the CVS version, critical > ones even. > > >>I don't see why they should wait for all outstanding bugs to be > > >>fixed before releasing. > > > > > > > > > That's why we've started with the bugfix releases. Critical, or a > > > set of minor bugs all fixed. But lets not release after every new > > > feature or whenever some code gets reformatted or some > documentation > > > gets added (since that can go to the website earlier). > > > > > > I probably got my wires crossed, but the point I wanted > to make was > > > that I think we should be fixing bugs before adding features, and > > > doing more testing before officially releasing plugins after > > > features are added. > > > > > > - 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] > > > --------------------------------------------------------------------- > 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]
