tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina Container.java
Date Fri, 09 Nov 2001 23:18:10 GMT


On Fri, 9 Nov 2001 costinm@covalent.net wrote:

>
> But that's nothing compared with the fact that none of this was discussed.
> If nobody comments on a proposal it doesn't mean unanimous aproval, but
> lack of interest - which is a good sign something is wrong.
>

This is always an interesting dilmemma in open source development -- how
much does the developer go on their own initiative versus discussing
everything?

I would suggest looking back at all the backwards-incompatible API changes
that were done as part of the 3.x refactoring process (3.0 --> 3.3).  They
fall into three categories:

* Discussed ahead of time (and/or proposed with lazy consensus).

* Committed and then accepted (lazy consensus) or refined based on
  feedback.

* Just committed, even if they broke old code.

All three happened, in significant percentages of cases, in 3.x (the
reason that "org.apache.catalina.util" existed in the first place is
because I got tired of Costin's changes breaking Catalina builds that
depended on "org.apache.tomcat.util" in the early days :-).  But the more
important point is that all three will *always* happen, unless we're
willing to slow things way down.

Arbitrary changes that break things are, in general, not ideal.  That's
what deprecating old interfaces is about (This got lots better later in
the 3.x process, for example).  If ServerSockeFactory doesn't compile
against the 4.0 branch, despite my attempt to leave a deprecated version
of the old class name, that's a bug in my deprecation, not a malicious
attempt to be incompatible.  It should be treated like any other bug.

On the other hand, refactoring by its very nature changes things (which is
why I'm smiling when I think about who is complaining here :-).  We have
to balance need/desire for improvement, maintaining APIs in exsting code
(even if it's not in the same package), readability, and all the other
usual pile of motivations for changing things.

>
> Costin
>

Craig


--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message