You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Vincent Massol <vm...@pivolis.com> on 2003/06/04 14:49:15 UTC
Committers let's agree on how we make changes to a plugin
Hi,
What do you think about the following process for making changes to a
plugin (and for accepting patches):
1/ Update xdocs/changes.xml (create it if it does not exist) and
describe the change
2/ Update the goals.xml/properties.xml and more generally the plugin
documentation if changes affecting users have been made
3/ Ensure that the version in plugin.xml is a SNAPSHOT version (i.e. not
delivered). Unless you're making a release of the plugin.
4/ Make sure the <version> section of project.xml is up to date
Almost everytime I make changes to a plugin I find that these simple
rules are not followed (Note: I know dIon is also careful about them).
What do you think?
Thanks
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Committers let's agree on how we make changes to a plugin
Posted by di...@multitask.com.au.
+1 on that one too
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Work: http://www.multitask.com.au
Jason van Zyl <ja...@zenplex.com> wrote on 05/06/2003 10:34:11 PM:
> On Thu, 2003-06-05 at 04:04, Rafal Krzewski wrote:
> > Jason van Zyl wrote:
> >
> > > Document it and it will more than likely be followed.
> >
> > I wish it would be so simple. Humans are lazy and forgetful, even the
> > best documenation won't change that. The most common case is that some
> > a person wants to apply just a tiny little fix to a plugin.
> >
> > I think that public scolding people that break the rules will be
> > neccessary addition to the documentation...
>
> Personally I would like a tool to help, but that will be a dream for
> some time. The releases for example: I don't think you can make quick,
> consistent and safe releases without a tool that performs all sorts of
> checks and helps you do most of the work. I realize how hard these tools
> are to write but ultimately will be the only real solution.
>
> > R.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> --
> jvz.
>
> Jason van Zyl
> jason@zenplex.com
> http://tambora.zenplex.org
>
> In short, man creates for himself a new religion of a rational
> and technical order to justify his work and to be justified in it.
>
> -- Jacques Ellul, The Technological Society
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Committers let's agree on how we make changes to a plugin
Posted by Jason van Zyl <ja...@zenplex.com>.
On Thu, 2003-06-05 at 04:04, Rafal Krzewski wrote:
> Jason van Zyl wrote:
>
> > Document it and it will more than likely be followed.
>
> I wish it would be so simple. Humans are lazy and forgetful, even the
> best documenation won't change that. The most common case is that some
> a person wants to apply just a tiny little fix to a plugin.
>
> I think that public scolding people that break the rules will be
> neccessary addition to the documentation...
Personally I would like a tool to help, but that will be a dream for
some time. The releases for example: I don't think you can make quick,
consistent and safe releases without a tool that performs all sorts of
checks and helps you do most of the work. I realize how hard these tools
are to write but ultimately will be the only real solution.
> R.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Committers let's agree on how we make changes to a plugin
Posted by Rafal Krzewski <Ra...@caltha.pl>.
Jason van Zyl wrote:
> Document it and it will more than likely be followed.
I wish it would be so simple. Humans are lazy and forgetful, even the
best documenation won't change that. The most common case is that some
a person wants to apply just a tiny little fix to a plugin.
I think that public scolding people that break the rules will be
neccessary addition to the documentation...
R.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Committers let's agree on how we make changes to a plugin
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Jason van Zyl [mailto:jason@zenplex.com]
> Sent: 04 June 2003 22:46
> To: Maven Developers List
> Subject: Re: Committers let's agree on how we make changes to a plugin
>
> On Wed, 2003-06-04 at 08:49, Vincent Massol wrote:
> > Hi,
> >
> > What do you think about the following process for making changes to
a
> > plugin (and for accepting patches):
> >
> > 1/ Update xdocs/changes.xml (create it if it does not exist) and
> > describe the change
> > 2/ Update the goals.xml/properties.xml and more generally the plugin
> > documentation if changes affecting users have been made
> > 3/ Ensure that the version in plugin.xml is a SNAPSHOT version (i.e.
not
> > delivered). Unless you're making a release of the plugin.
> > 4/ Make sure the <version> section of project.xml is up to date
> >
> > Almost everytime I make changes to a plugin I find that these simple
> > rules are not followed (Note: I know dIon is also careful about
them).
> >
> > What do you think?
>
> +1
>
> Document it and it will more than likely be followed.
I have started here:
http://nagoya.apache.org/wiki/apachewiki.cgi?Maven/PluginModificationGui
delines
I have also linked this page from the Development process page of the
maven web site (but I haven't republished it yet).
Thanks
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Committers let's agree on how we make changes to a plugin
Posted by Jason van Zyl <ja...@zenplex.com>.
On Wed, 2003-06-04 at 08:49, Vincent Massol wrote:
> Hi,
>
> What do you think about the following process for making changes to a
> plugin (and for accepting patches):
>
> 1/ Update xdocs/changes.xml (create it if it does not exist) and
> describe the change
> 2/ Update the goals.xml/properties.xml and more generally the plugin
> documentation if changes affecting users have been made
> 3/ Ensure that the version in plugin.xml is a SNAPSHOT version (i.e. not
> delivered). Unless you're making a release of the plugin.
> 4/ Make sure the <version> section of project.xml is up to date
>
> Almost everytime I make changes to a plugin I find that these simple
> rules are not followed (Note: I know dIon is also careful about them).
>
> What do you think?
+1
Document it and it will more than likely be followed.
> Thanks
> -Vincent
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Committers let's agree on how we make changes to a plugin
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: dion@multitask.com.au [mailto:dion@multitask.com.au]
> Sent: 10 June 2003 09:42
> To: Maven Developers List
> Subject: Re: Committers let's agree on how we make changes to a plugin
>
> Big +1 from me....Let's get it documented somewhere!!!
Done here:
http://nagoya.apache.org/wiki/apachewiki.cgi?Maven/PluginModificationGui
delines
and linked in the "development process" page.
-Vincent
> --
> dIon Gillard, Multitask Consulting
> Blog: http://blogs.codehaus.org/people/dion/
> Work: http://www.multitask.com.au
>
>
> "Vincent Massol" <vm...@pivolis.com> wrote on 04/06/2003 10:49:15
PM:
>
> > Hi,
> >
> > What do you think about the following process for making changes to
a
> > plugin (and for accepting patches):
> >
> > 1/ Update xdocs/changes.xml (create it if it does not exist) and
> > describe the change
> > 2/ Update the goals.xml/properties.xml and more generally the plugin
> > documentation if changes affecting users have been made
> > 3/ Ensure that the version in plugin.xml is a SNAPSHOT version (i.e.
not
> > delivered). Unless you're making a release of the plugin.
> > 4/ Make sure the <version> section of project.xml is up to date
> >
> > Almost everytime I make changes to a plugin I find that these simple
> > rules are not followed (Note: I know dIon is also careful about
them).
> >
> > What do you think?
> >
> > Thanks
> > -Vincent
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Committers let's agree on how we make changes to a plugin
Posted by di...@multitask.com.au.
Big +1 from me....Let's get it documented somewhere!!!
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Work: http://www.multitask.com.au
"Vincent Massol" <vm...@pivolis.com> wrote on 04/06/2003 10:49:15 PM:
> Hi,
>
> What do you think about the following process for making changes to a
> plugin (and for accepting patches):
>
> 1/ Update xdocs/changes.xml (create it if it does not exist) and
> describe the change
> 2/ Update the goals.xml/properties.xml and more generally the plugin
> documentation if changes affecting users have been made
> 3/ Ensure that the version in plugin.xml is a SNAPSHOT version (i.e. not
> delivered). Unless you're making a release of the plugin.
> 4/ Make sure the <version> section of project.xml is up to date
>
> Almost everytime I make changes to a plugin I find that these simple
> rules are not followed (Note: I know dIon is also careful about them).
>
> What do you think?
>
> Thanks
> -Vincent
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org