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 right now.

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?

-Stuart-



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-devel

Reply via email to