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
