You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Clint Checketts <ch...@gmail.com> on 2011/03/21 21:22:14 UTC
Wicket mentioned at Server Side Symposium
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
Re: Wicket mentioned at Server Side Symposium
Posted by Jörgen Persson <ma...@jorgenpersson.se>.
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 <ma...@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 <ch...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
Re: Wicket mentioned at Server Side Symposium
Posted by Frank van Lankvelt <f....@onehippo.com>.
On Mon, Mar 21, 2011 at 9:52 PM, Martijn Dashorst <
martijn.dashorst@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 <ch...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@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 • info@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.
Re: Wicket mentioned at Server Side Symposium
Posted by Martijn Dashorst <ma...@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 <ch...@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org