tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remy Maucherat" <rmauch...@home.com>
Subject Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina Container.java
Date Sun, 11 Nov 2001 00:01:07 GMT
> On Sat, 10 Nov 2001, Remy Maucherat wrote:
>
> > Obviously, there are/were still some omissions and small problems.
>
> Well, it's not that obvious. I have seen little discussion on what's
> broken and how to fix it - and I remember reading in some mails that 4.1
> will be 'backward compatible with 4.0' - which implied the reverse ( i.e.
> the 4.0 API is 'good enough' and will not change ).
>
> IF ther are only 'few omissions and small problems' - then it's even less
> obvious. Are those small enough that we can accept them as a price for
> stability ? This is not something you can take as 'obvious'.
>
> As you know I don't like the 4.0 API - I think it's far too complex,
> but I can accept some people like it - I'm not going to vote one
> way or another, but I want to know that this issue was decided
> ( for example mod_jk has 'facades' to 3.3 and 4.0, and we may need
> to add another facade for 4.1 if this is not going to be compatible
> with 4.0 )

What I think on the subject depends on what you define as "breaking the
API". If adding some methods like I did recently is not ok, then I will vote
against API stability. If reasonable method addition is ok, but removal
isn't, then I think we can reach an agreement.

> > You can always improve and refactor, so the core won't stay frozen.
>
> If the problems are 'few and small' - I can't see why ? For example
> a number of people consider the current API in 3.3 to be good enough,
> and that improving it is less valuable than keeping it stable.
>
> I love refactoring - as long as it has a start and an end and you
> have a clear target and know what is broken and how to fix it.

If I remember well, you stated multiple times during 3.3 dev that you were
done, only to come back with even more drastic (and mostly unexpected)
refactorings.

> > modules. People may want to see hype-friendly version numbers, so I
suggest
> > we increment the second digit, even if what we call 4.1 is in fact 4.0.3
+
> > tons of new modules. Does it make sense ?
>
> No, it doesn't.
>
> It could make sense if the API would be backward compatible and the
> modules would be clearly separated.

They are. If you can build and run without them, then it's a module even if:
- the code ends up in the same JAR
- the code is in the same CVS repository

> But even then - what if you want to make a major API change ? You can't
> call it 5.0 ( since that would imply servlet 2.4 ).

We're not talking about the user API here (which is the Embedding API + the
servlet API), but about the internal API. I see much less problems with
modification to that API.

Remy


--
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