I think we're committed to solving problems on the oacs-4-6 branch ASAP, but as Jeff notes can't guarantee that we don't mess up. I did full testing of the PG version after making my rather massive changes but didn't realize I'd accidently walked over three or four oracle XQL files as well.
I'd love to keep our minor number upgrades really minor in the future - when things stabilize more. Right now we're making such great progress that being more agressive on the oacs-4-6 branch makes sense and, as Jeff says, merging forward from there's a lot easier than vice-versa (all those localization changes on the HEAD would make it very laborious to pick out the proper changes)
As things get more stable and as we get better at pushing out maintenance releases in a timely fashion hopefully the need to pull CVS copies in order to keep abreast of major bug fixes will be reduced.
Remember the PostgreSQL history ...
OpenACS 3.x, when first released, *required* PG 6.5 Beta, it simply wouldn't run on the PG 6.4 production release.
For a couple of OpenACS 3.x releases after the very first one, we required either Beta or the very latest production release of PG due to the pace at which they fixed bugs that we kept stumbling over.
Now, for some time, we've been able to work with at least one version older than the current. That's because their project's matured to the point where the current version no longer feels so seriously broken that one can't wait until the next version to come out.
Of course I'm ignoring the mini-fiasco in PG 7.3 with default timestamp semantics changing from with to without timezone but in general we've been able to work with PG 7.N.x and PG 7.N-1.x (where N is the major release).
Hopefully after we swallow the elephant known as OpenACS 4.7 (an elephant due to all the localization work) our stuff will mature, too ...
