tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: Cluster maintenance and improvement
Date Thu, 23 Feb 2006 16:20:56 GMT
Hi Remy,

>> 1. If we don't primary/secondary will not be available until TC.6
>> 2. TC 6 doesn't have a skeleton nor a date yet.
> It could have that tomorrow.
> I agree with Peter: it's obvious no one should be doing major 
> refactoring of existing components in 5.5.x. You could create a separate 
> "cluster2" module if you still want to do the work in Tomcat 5.5.x, 
> however.

So in general we have three options:

A) maintenance branch inside 5.5.15
B) cluster2 module
C) making changes in TC 6

Whichever way we choose, I think we need two lines of development:

a) one which tries to stick closely to the 5.5.15 code and only picks up 
security fixes and changes needed to keep compatibility with 5.5.x.

b) another one which gets all the refactoring, new features and 

We have to make decisions:

- maintenance for a): If we let die a) for TC 6, we should document that 
decision, so would deprecate a) now. This sounds a little harsh, but 
that's in fact what we then do. It would be nice to support a) at least 
12 months after announcement of deprecation.

- release bundles: I think a) and b) should be available for download 
when a new 5.5 release is done. I don't really care about having 
seperate download file or not.

- default configuration entries in server.xml

Concerning A), B) or C):

Remy: what do you think, about how long dows it take to make a first 
alpha releaseof TC 6. I didn't follow closely the state of Specs and 
implementations. I expect that to still need 2 to 3 months. If I'm 
right, that means C) will not work out for Filip, because then he lacks 
the necessary amount of users playing around with the new code.

Decision between B) and C) depends more on the kind of message one needs 
to send to the user base. My impression is, that at the end the cluster 
code will have huge differences to it's state today and it would be more 
correct to have cluster2. But I could live with all parallel options, as 
long as we keep the old code compatible with 5.5.x and we document the 
plan for the future (maintenance/deprecation) for the user base.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message