Re: Add a new method to an interface in 7.x

[Andrea Del Bene]

Maybe I'm wrong but it doesn't look an heavy change....I think it falls 
in the acceptable category described by Martijn.
My best solution would be to discuss API breaks on a case by case basis.
If breaks happen on a minor part of our API, I am not against them,
even if they are late in the game. Say if they typically would break 1
class or at most 10 classes in a large application (100+ pages). So
IChoiceRenderer would be a bad thing to break. Changing the interface
of ISomeInterfaceInExtensionsOnly10PeopleAreUsingWorldWide would not
be a problem in my opinion.

Martijn



On Mon, Feb 9, 2015 at 10:29 AM, Martin Grigorov <mgrigo...@apache.org> wrote:
Hi,

In https://issues.apache.org/jira/browse/WICKET-5833 I propose to add a new
method to 
org.apache.wicket.protocol.ws.api.registry.IWebSocketConnectionRegistry
to return all we bsocket connections per user session.

This is an API break - with
org.apache.wicket.protocol.ws.WebSocketSettings#setConnectionRegistry()
the application may provide custom impl.

I've prefered to stop break the APIs and release 7.0.0 sooner but even
without API breaks we keep delaying it.

So I want to ask other devs what do you prefer to be the policy ?

- no more API breaks if they are not really/urgently needed (as Andrea's
refactoring of ICrypt)

- no more API breaks if there is a workaround (WICKET-5833 could be worked
around with a custom IWSCRegistry and casting in the user code)

- make API break because we are still in Milestone phase

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov