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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
