I'm not trying to start a war here and I guess this will be my only contribution to this thread so with the risk of being punished by the wicket community, I guess the speaker said like he said because wicket release numbering doesn't follow "normal" version numbering (with "normal" I mean what most other projects use). If you have x.y.z, then you should change x: if you have API breaks y: if you have new development, internal improvements or non critical bug fixes and there isnt an API break z: if you have to release a hot-fix for due to a serious bug.
Releases with this numbering will on the other hand require more maintenance. A z release should be made for all previous releases which contains the bug, provided that the 'old' release is still supported. It could be the last X number of y releases or perhaps all releases made the last number of X months. /J 2011/3/21 Martijn Dashorst <martijn.dasho...@gmail.com> > 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 >
