Andrus Adamchik wrote:
> Anyway, given that a) this is still Beta and b) even with our
> deprecation attempts, Beta 1 introduced tons of incompatibilities with
> Alpha 6, I vote "-0" on this, meaning that I have no serious objections
> to removing it now.
done, everything is cleaned up now. I also updated the release notes for
the MySQL PK fix.
> But when we get to a point of deprecation between stable releases (say
> 1.0 -> 1.1), I would insist on keeping deprecated methods as long as
> possible (maybe at least between the "major releases, say 1.x -> 2.0).
> Cause we will be dealing with people upgrading their production
> systems, and migration path should always be reasonable with no excuse
> of the "OpenSource"-ness of the product.
Couldn't agree more on the production aspect, but let me explain why I'm
always so eager to delete stuff (I think Dirk will agree with me here,
since we've worked together in the past). I _always_ work with the highest
possible compiler warning level turned on (-Wall -Werror when I work in
C/C++/ObjC - people really hate me for that at first, but it's the
cheapest way to kill problems right before they start to spread), and just
cannot sleep right when there are yellow tasks in my eclipse task bar. In
fact if I were in control of the compiler, warnings would be eliminated
and always turned into errors. I also realize it can sometimes be annyoing
at development time..so how about this: between releases we allow unused
private variables/methods, unused imports, use of deprecated API (not the
API itself) etc; for a release all these are turned on and cleaned up.
Since eclipse 2.1 can keep compiler settings per project, this should be
easy to do.
Holger
This archive was generated by hypermail 2.0.0 : Wed Apr 30 2003 - 08:41:25 EDT