On 25.03.2009 19:33, Costin Manolache wrote:
On Wed, Mar 25, 2009 at 11:17 AM, Rainer Jung<rainer.j...@kippdata.de>wrote:
Thanks Costin for coming back to this topic. Collecting ideas for major
redesigns could be done, but that was not my intention. I don't see enough
time available for doing the big stuff, but I want to proceed committing
time slices for incremental improvement. So I would like to stabilize 1.2
now (apart form bug fixes), because I think we are in good shape there now,
and open up another line of development (1.3), where implementing new
small/local features, which always includes the risk of introducing new
bugs, can be done without posing any risk on 1.2.
What about - release 1.2.28, create a branch for it, then start adding the
features in trunk. After you add few
features and are ready for a release - we can decide how to name it (1.2.29
or 1.3.0 ), based on how much
and what changed. I would only switch to 1.3.0 name if there are
backward-incompatible changes - keep in mind
many people will be reticent to switch ( and test ) if they assume 'big
changes'.
I think one of the most important (and easy) changes, but also one that
somehow is incompatible will be to activate a lot of settings by
default, which are now disabled by default. In particular setting
reasonable values for the various timeouts.
When we added a new timeout or similar things in the past, we didn't
want to change the out of the box experience of the users (although I'm
pretty sure, it would have improved), in order to make updates as much
transparent as possible.
Therefore now users have to add lots of configuration parameters to the
config in order to get a nice runtime behaviour. This is a major pain
and setting reasonable defaults scratches this itch but at the same time
"activates" all the related features, that were turned of by default
until now.
Of course we can't ignore the adoption problem for new major releases.
But my strategy would be to now stop adding new features to 1.2 and
implement enough of those in the first say four or five 1.3 releases to
make migrating interesting for enough users, so we start getting again
enough feedback from the field.
If we go on putting new features in 1.2, and we get to a point, where
introducing an incompatibility is necessary, then we might end up having
not enough interesting features left to motivate users to switch.
I wish we used Ubuntu-like release names :-)
Indeed. I don't know whether all of these
http://en.wikipedia.org/wiki/Thousand_Islands_%28Indonesia%29
have an individual name, but they could provide enough names for a lot
of future releases (=105). We would have to find a geographical analogy
of compatibility though :)
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
