You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Paul Spencer <pa...@apache.org> on 2004/08/11 10:25:01 UTC
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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Plugin release procedure, was Re: Dashboard plugin release status?
Posted by Carlos Sanchez <ap...@carlos.cousas.net>.
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:epugh@upstate.com]
> 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:paulsp@apache.org]
> > 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: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Plugin release procedure, was Re: Dashboard plugin release status?
Posted by Eric Pugh <ep...@upstate.com>.
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:paulsp@apache.org]
> 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: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org