quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Gallacher <...@jgassociates.ca>
Subject Re: 3.2.9-rc2 FieldStorage Problems (was Re: mod_python 3.2.9-rc2 available for testing)
Date Fri, 23 Jun 2006 21:01:53 GMT
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

Mime
View raw message