Nicolas Lehuen wrote:
2005/9/8, Jorey Bump <[EMAIL PROTECTED]>:
Jim Gallacher wrote:
Nicolas Lehuen wrote:
Well, why not keep our plan of releasing 3.2 ASAP and save this
problem for a later 3.2.x as a bug fix ?
Making subsequent bug-fix releases should be fast and easy. We cannot
afford to repeat the long hiatus between 3.1.3 and 3.2, with a long
period of time without any official bug fix.
I agree that 3.3 may come later, but we definitely should be able to
release 3.2 bugfixes version as often as possible. This will save us
and our users a lot of time, allowing us to stop writing "yeah, we
know this bug, it's already fixed in SVN but you'll have to wait an
undefinite time for the fix to go public".
+1
It's always tempting to make one last change, fix one more bug, but then
the release never happens. I think everyone has the will to move
mod_python forward, we just need a little more discipline. There are
lots of things we can do in 3.3, but I for one am not motivated to work
on these until 3.2 is out. Lets get this puppy out the door and then
have a discussion on plans and priorities for 3.3 with a view to
reducing the time between bug fixes and major releases.
Would it help to adopt a naming convention where odd minor versions are
for development, and even minor versions are stable/bug-fix-only? This
would be a convenient time to adopt it. In some environments, this gives
developers a place to add new features (3.3.x) while the first stable
release (3.2.0) is getting bug squashed. As a user, it makes things a
lot clearer that a certain version is still in development when you lust
after a new feature it offers.
Just a thought...
Yeah, why not.
In any case, we should maintain a separate 3.2 branch with only bug
fixes while developing the 3.3 version on the trunk (and merge the
bugfixes from the 3.2 version into the 3.3 trunk, of course).
We haven't done this for the 3.1 and 3.2 version, so everybody will
need to upgrade to 3.2 even if they want a single bugfix. This is not
a really bad thing this time, but next time, if we start to "fool
around" and break some compatibility (think "new import system" here
:), we should make sure we don't force our users to upgrade just to
get one bugfix.
As Jorey points out, this is a good time to discuss this.
I'm not opposed to the even/odd numbering, but I'm not sure it's really
necessary. Does anyone really envisage making development snapshots
available as tarballs? I'm a big fan of subversion. If anyone wants to
play around with the development branch it's just as easy to grab a copy
of mod_python/trunk with svn as it is to download a tarball. If we are
not making development releases then we don't need to number them.
Beyond that, I agree we should have a 3.2 branch for bugfixes, and I
think we need it now. It's just too tempting to mess around with code in
mod_python/trunk which could screw up our close-to-golden 3.2 release.
I'd like to suggest "branches/release-3.2" as the name. (Note the lack
of a patch level in the name). Any further beta's and the final release
would be generated from this branch, with mod_python/tags reserved for
snapshots.
As far as some future version breaking compatibility, I favour a bigger
jump in the major number: 3.2 -> 4.0. This is server software after all,
and some people may prefer to maintain an older version for a longer
period, foregoing new features in favour of the tried and true.
Incrementing the major number makes it more obvious that an upgrade may
cause some problems. But I guess that discussion is sometime *way* in
the future. :)
Jim
