Can't you mention the issue in some kind of «release errata»
with a link to JIRA?
Sure. I'll happily keep that for Martijn to do. I'm done with this issue.
Eelco
-1: change the parameter type.
+0: add a new method to the class
I doubt this is actually something that needs fixing in 1.2.x though.
If someone desperately needs it, it is an easy fix in their own
application, and therefore I think that adding a new method will also
consist an api break.
why are we still arguing about this?
just deprecate the damn method already and add the variant
-igor
On 2/18/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
If the break is hypothetical, then why not leave it in there, perhaps
using @deprecated?
If there is just one user depending on it,
On 2/18/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
why are we still arguing about this?
just deprecate the damn method already and add the variant
Because that's a lame 'solution'. Deprecate would be ok if the method
did actually return normally but just wouldn't work like expected. In
this
look this is fixed properly in 1.3 and up. we agreed no api breaks in 1.2.x.
you can interpret it one way, martijn interprets it another. for him
removing a method, usable or not, is an api break. whatever. who cares?
1.2.x is in maintenance mode. we should concentrate on 1.3 instead of
wasting
On 2/18/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
look this is fixed properly in 1.3 and up. we agreed no api breaks in 1.2.x.
you can interpret it one way, martijn interprets it another. for him
removing a method, usable or not, is an api break. whatever. who cares?
1.2.x is in maintenance
http://issues.apache.org/jira/browse/WICKET-215 is really simple to
fix, but requires an API break. However, it's current state can't even
be used, so I'm sure this won't actually break any existing clients.
I'd like to apply this for 1.2.x.
Your votes please?
Eelco
