On Mon, Mar 21, 2011 at 9:52 PM, Martijn Dashorst < martijn.dasho...@gmail.com> wrote:
> 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. > > +1 Such an API gives way to a utility library that makes up for the stagnation, taking experience into account on a higher level. Thereby it effectively becomes the API itself. In my experience, .z wicket upgrades are a no-brainer, the .y upgrade I've seen gave me a working build in a day; remaining upgrade steps (deprecation / generification) can be dealt with when touching the code for new development. cheers, Frank > 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 > > -- Hippo Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522 4466 USA • San Francisco 755 Baywood Drive, Second Floor • Petaluma, CA. 94954 • +1 877 414 4776 (toll free) Canada • Montréal 5369 Boulevard St-Laurent #430 • Montréal QC H2T 1S5 • +1 (514) 316 8966 www.onehippo.com • www.onehippo.org • i...@onehippo.com ________________________________________________________________ This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately.
