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]
