From: Stuart Donaldson <stu@as...> - 2003-01-11 06:20:45
Because we have so many people apparently working from the CVS trunk, I
think there is a strong bias towards keeping the trunk stable. In my
case, I am extra cautious about committing changes in CVS, and in some
cases sit on changes for a long time in hopes of verifying that they are
stable. Or I'll submit them as patches in the hopes that someone else
will review it before it gets committed to CVS. In other cases, I
someone may commit a new version of something with a "New" tag embedded
in the name.
In order to move towards a new release, it appears that there are a few
things that need doing which have the potential to break code which is
currently expecting the current CVS version.
A couple of things that come to mind such as adopting some of the New
items. (ie: NewThreadedAppServer, serverSideInfoForRequestNewAlgorithm,
etc...) We had discussed a while back adopting the policy that in the
next release, the * New * items would be renamed to their original
names. This will break anybody that is currently trying to use them
I would really like to commit my subclassing of ThreadedAppServer, but I
have held off because of the risk it might destabilize the trunk.
There is probably a fare amount of code cleanup that some might like to
do, but they hesitate because of the risk of destabilization.
Should we just jump in and make some of these changes? Or should we
perhaps advertise a period where the CVS trunk may be a little less
stable? Should we put up an interim snapshot tarball?
I don't know that there is all that much time consuming stuff to do
here, but more a matter of not wanting to break something that people
have come to expect as being mostly stable.
Anybody else have any ideas? Am I just being too cautious?