It also depends on how much work it would be to implement the interface method.
Martijn On Mon, Feb 9, 2015 at 10:43 AM, Martijn Dashorst <[email protected]> wrote: > 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 <[email protected]> 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 > > > > -- > Become a Wicket expert, learn from the best: http://wicketinaction.com -- Become a Wicket expert, learn from the best: http://wicketinaction.com
