Re: internal voting

On Sat, 11 May 2002, Tom Lane wrote:

> 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.

Ah, I'm just composing an email on this subject destined for the -interfaces
list.

> 
> 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.

Really, I'd like interested parties to have look at waht I'm posting to
-interfaces so they can shoot down my ideas on this.


-- 
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants