On 2/26/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
I see it as a pretty major api break. Considering that everyone on our
project uses the construct to return quickly to the previous page,
which is a very valid usecase. I can only imagine that many others
have used this construct as well.
I *really* think that removing *existing* api because it /can/ be used
incorrectly instead of educating through documentation is not the way
to go.
We disagree then. And it is unfortunately not just /can/ but rather
/is/ and /will be/.
I am also against renaming it, again because the API break is significant.
I also don't see a problem with deprecating the constructor and or
class, and removing it in 1.4: this gives our projects, and those of
our users with *LEGITIMATE* uses of it, the chance to migrate. It will
also give users with wrong uses the message that they are using it
wrong and a chance to do somethign about it at a moment that is
convenient for them. As for 2.0 I don't mind removing it as the API is
already much different (due to the constructor change).
Let's go that path then.
Deprecation is there for a reason: API migrations. I think we have a
valid usecase here and should use that instead of blatently removing
any constructor/class that is/may be widely used.
Unfortunately, it often takes forever to remove deprecations, and
users can just happily use them and still get pissed off when someday
they are removed. I like to break early when we can. But well, that is
a discussion that is more generic than needed for this thread.
As for the veto, I think we all have a right to disagree here: that is
what I'm doing. Since when is rubber stamping proposals 'the Apache
way'?
Sure you have that right as anyone else in the team has. I hope you
don't take it too lightly though; too much use of veto's can cripple
any group process. We have always respected your vetos, even before we
were trying to play by the Apache rules, and we will in the future.
But vetos are usually pretty frustrating for the other's that are
veto-ed away, so don't expect me (or anyone else) to be cheery about
it.
Eelco
