While we strive to keep binary compatibility between minor releases, i.e. the z releases of an x.y.z release path, sometimes things slip by. In principle we only allow security or blocker issues to break the API in a .z release. So we strive to make the upgrade path of 1.4.0 to 1.4.16 to be just a version number change, with an API surface the size of Wicket's it is nigh impossible to achieve 100% binary compatiblity between all minor releases (.z releases).
If the speaker is talking about the y part, then yes we allow breakages and possibly even large ones. But those are always fairly easy to upgrade. The upgrade from 1.3 to 1.4 was mainly generics: a painful upgrade, but worth the effort. It could've been a x release, but we only modified the type parameter, and the rest of the API was only changed to support the generification. We voted upon the release number and with our previous 2.0 fiasco still in memory we decided to up the y part only. With Wicket 1.5 we improved the internals considerably, and improved the API as well. The upgrade path is detailed in our migration guide in the wiki. The upgrade from 1.4 to 1.5 should be not too much work. I'd rather have a framework that breaks some API in minor ways with each .y release, than a stagnant framework that is afraid to improve on its API and internals. So while he technically has a point, I think it is a category z point. Not a major one. Martijn On Mon, Mar 21, 2011 at 9:22 PM, Clint Checketts <checke...@gmail.com> wrote: > Take the following with a grain of salt since I was told by a friend, of a > friend that attended the Server Side Symposium last week. I don't have any > of the details either so bear with me. > > Apparently in a session related to 'corporations using open source' the > speaker asked if any companies were using Wicket. He cautioned that Wicket > was an example of mis-managing by being known to break it's APIs in minor > point-releases. > > In my experience with the Wicket API, I've only seen major API changes in > the major releases: 1.3 -> 1.4 and the upcoming 1.5. (In my book API > *additions > *like adding onConfigure don't count) So of course I stood up for Wicket. > Even when I've proposed changes myself the core developers have done a great > job of not breaking APIs. > > So, does anyone else know what this speaker may have been referring to > regarding API breakages? > > -Clint > -- Become a Wicket expert, learn from the best: http://wicketinaction.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
