Re: internal voting

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> We went through a very similar situation with the JDBC driver a release
> ago. A number of people had developed fixes or features for the driver
> and no one was collecting them. We've got those people working on the 7.2
> branch and everything worked out well. Yes, this meant that the features
> and fixes were not immediately available in the 7.1 branch.

Au contraire --- what the JDBC folk did (and still are doing) was to
make "unofficial" releases consisting of snapshots pulled from their
chunk of the CVS tree. There were people making use of the "7.2 branch"
of JDBC long before the 7.2 server went beta, let alone final.

Now this worked only because the JDBC driver makes a point of working
with older server versions as well as current, so it was possible to
use the updated driver with 7.1 and even older servers. I don't know
whether pgaccess does or should have a similar policy, but if it does
then the same approach should work well for it.

The alternative of maintaining a separate CVS tree and a separate
release schedule would really force exactly that policy on pgaccess
anyway --- if your releases aren't tied to the server's then you can
hardly expect to be sure which server version people will try to use
your code with.

On the other hand, if the pgaccess developers would rather maintain
separate pgaccess versions for each server version, I see no reason
why they couldn't do that in the context of our CVS. They could work
in the REL7_2 branch for now (and make releases from it) then merge
forward to HEAD when they want to start thinking about 7.3 issues.
Or double-patch if they want to work on both versions concurrently.

regards, tom lane