Changing (internal) interface signatures in a plugin

[Anders Hammar <an...@hammar.net>]

Just want to check what the general opinion is about changing method
signatures of Plexus component interfaces in our plugins for a minor
version release.

In a perfect world it would be awesome to always keep backwards
compatibility and at least never do any changes unless a major version. But
as we all know this comes at a cost (and also sometimes forces one to
create a less good solution). So I wonder if this is important if it's a
component defined in a plugin and just used in that plugin. Sure, some
advanced user could in theory have written their own implementation
possibly using that. Highly unlikely though I think.

What's your thoughts? Currently I'm looking at ARCHETYPE-358 and the
archetype plugin which has a few internal components.

Personally I'm +1 as my take is that we're always telling the users not to
have a dependency to (extend) a plugin. Separate libraries (like there are
in the maven-archetype project) is different thing I think.

/Anders

Re: Changing (internal) interface signatures in a plugin

[Anders Hammar <an...@hammar.net>]

Well, to be absolutely clear, to fix that issue I might need to make bigger
changes (incl. public methods) as there should probably be some design
changes. The patch is not complete.

But I'd like this discussion to be generic and not specific to this issue.

/Anders


On Tue, Jan 29, 2013 at 3:59 PM, Olivier Lamy <ol...@apache.org> wrote:

> +1
> And the patch is a signature change on a private method so not a real
> issue.
>
> 2013/1/29 Anders Hammar <an...@hammar.net>:
> > Just want to check what the general opinion is about changing method
> > signatures of Plexus component interfaces in our plugins for a minor
> > version release.
> >
> > In a perfect world it would be awesome to always keep backwards
> > compatibility and at least never do any changes unless a major version.
> But
> > as we all know this comes at a cost (and also sometimes forces one to
> > create a less good solution). So I wonder if this is important if it's a
> > component defined in a plugin and just used in that plugin. Sure, some
> > advanced user could in theory have written their own implementation
> > possibly using that. Highly unlikely though I think.
> >
> > What's your thoughts? Currently I'm looking at ARCHETYPE-358 and the
> > archetype plugin which has a few internal components.
> >
> > Personally I'm +1 as my take is that we're always telling the users not
> to
> > have a dependency to (extend) a plugin. Separate libraries (like there
> are
> > in the maven-archetype project) is different thing I think.
> >
> > /Anders
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Changing (internal) interface signatures in a plugin

[Olivier Lamy <ol...@apache.org>]

+1
And the patch is a signature change on a private method so not a real issue.

2013/1/29 Anders Hammar <an...@hammar.net>:
> Just want to check what the general opinion is about changing method
> signatures of Plexus component interfaces in our plugins for a minor
> version release.
>
> In a perfect world it would be awesome to always keep backwards
> compatibility and at least never do any changes unless a major version. But
> as we all know this comes at a cost (and also sometimes forces one to
> create a less good solution). So I wonder if this is important if it's a
> component defined in a plugin and just used in that plugin. Sure, some
> advanced user could in theory have written their own implementation
> possibly using that. Highly unlikely though I think.
>
> What's your thoughts? Currently I'm looking at ARCHETYPE-358 and the
> archetype plugin which has a few internal components.
>
> Personally I'm +1 as my take is that we're always telling the users not to
> have a dependency to (extend) a plugin. Separate libraries (like there are
> in the maven-archetype project) is different thing I think.
>
> /Anders



-- 
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Changing (internal) interface signatures in a plugin

[Benson Margulies <bi...@gmail.com>]

+1 on changing. no one is forced to upgrade.

On Jan 29, 2013, at 1:19 PM, Anders Hammar <an...@hammar.net> wrote:

> Just want to check what the general opinion is about changing method
> signatures of Plexus component interfaces in our plugins for a minor
> version release.
>
> In a perfect world it would be awesome to always keep backwards
> compatibility and at least never do any changes unless a major version. But
> as we all know this comes at a cost (and also sometimes forces one to
> create a less good solution). So I wonder if this is important if it's a
> component defined in a plugin and just used in that plugin. Sure, some
> advanced user could in theory have written their own implementation
> possibly using that. Highly unlikely though I think.
>
> What's your thoughts? Currently I'm looking at ARCHETYPE-358 and the
> archetype plugin which has a few internal components.
>
> Personally I'm +1 as my take is that we're always telling the users not to
> have a dependency to (extend) a plugin. Separate libraries (like there are
> in the maven-archetype project) is different thing I think.
>
> /Anders

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org