Max Bowsher wrote: > Jim Gallacher wrote >> Since a 3.3 release is at least a few months away, I think we can take >> our time and give this some careful consideration. Maybe the best plan >> is to leave FieldStorage as-is for legacy applications and start fresh >> on a brand new FieldStorageNG class, without worrying about backwards >> compatibility? > > There are projects which allow compatibility breakage only on major > (i.e. 3.x -> 4.x) version bumps [e.g. APR, Subversion] and those which > allow it on minor (i.e. 3.2.x -> 3.3.x) version bumps [e.g. Apache > HTTPD, Berkeley DB]. Into which category does mod_python place itself?
I don't think we have any formal mod_python policy. If I had to guess I'd say allow breakage on minor version bumps, for 2 reasons: 1. We are an Apache httpd subproject, so that would be consistent with our parent project. 2. API changes should be fairly rare and of a minor nature anyway and requiring a major version bump seems like overkill. Major bumps should be reserved for the really big events, such as 2.7 -> 3.0, where apache 1.3 support was dropped as mod_python transitioned to apache 2.0. My personal feeling is that we should be very conservative about API changes. Users should be able to depend on mod_python as a stable platform on which to build their frameworks and applications, and not have to worry about refactoring their code every 6 months because we've run amok with our changes. Jim
