I still don't understand why don't you just ship 2 config files, or even change the defaults and just provide a config that restores old values. But it looks like a reasonable plan - next step will be to ship 1.2.28, label it - and branch if you want ( branches are cheap if you don't plan to do a lot of work in them ), add the new features to trunk and we can probably postpone the naming of the release after 1.2.28 until it's ready :-)
Thanks for all the information and work you're doing, it's good to know what are the plans. Costin On Wed, Mar 25, 2009 at 5:28 PM, Rainer Jung <rainer.j...@kippdata.de>wrote: > 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 > >
