One of the problems with maintaining PEAR DB is that it’s a little hard to plan out future releases, given that it only gets bug fixes and no new features. The approach I’ve been using since the release of DB 1.7.8 (the last big catch-up release) is to push out new releases more or less as I fix stuff, which tends to result in numerous small releases, sometimes quite close together. This works, but I know that it would have annoyed me when I was wearing my sysadmin hat, so I’m going to try something different for the next little while.
What I’m going to do for now is to plan a release on the roadmap for the end of each calendar month. Non-critical bugs, instead of causing a full release, will instead be fixed in CVS and a release will be pushed out at the end of the month with that fix and any others that went in. Obviously, if there are no bugs reported during the month, then the release won’t occur and I’ll instead change the roadmap to push the release back a month.
Critical bugs will still get the immediate attention they need, and releases will be made as quickly as possible for them, rather than waiting for the end of the month. However, I think it’s important not to overload programmers, packagers and sysadmins with overly frequent releases, so we’ll give this a whirl for now.
Incidentally, you can assume that DB 1.7.11, which I’ve just released with a FrontBase-only fix, is the end of March release.
(Oh, side note I forgot to put in the initial post: I’ve re-enabled trackbacks on DB for now. If the spam starts annoying me again, then I’ll disable them once again. Here’s hoping.)