On Fri, 2 Aug 2002, jtv wrote:
> Looking at it that way, it seems to me that the proper approach is to
> cut out all interfaces that don't talk to the backend themselves--e.g.
> the ones that build on top of libpq, like libpq++ and libpqxx do.
This is what my opinion is ... what I'm setting up right now with CVS is
meant to be a middle ground ...
> Of course my humble but thoroughly biased opinion is that libpq++ be
> marked "legacy."
No doubt, but, if we didn't "push" one interface over another, then it
would be up to the end-users themselves to decide which one to install ...
> > By branching out the fat, we make it *easier* for someone to take on
> > development of it ... would libpqxx ever have been developed if Joergen
> > could have just worked on libpq++ in the first place, without having to
> > submit patches?
>
> Yes.
Okay, then let's word it another way ... if libpq++ *wasn't* in the
repository and part of the distribution, would you have a) started working
on it sooner? b) would you have made it public earlier? c) would ppl
have started to use it and stop'd using libpq++?
Basically, with libpq++ in the distribution, we are endorsing its use, so
if we didn't put libpqxx into the repository, would ppl switch from the
'endorsed' to the 'unendorsed' version?
By having libpq++ in the repository, we are adding weight to it that it
wouldn't have if it were outside of the repository, making it more
difficult for 'alternatives' to pop in ...
> For the more general case, there's the problem of release management: who's
> going to be taking care of synchronizing releases? This may require some
> new infrastructure, such as a mailing list dedicated to the process, or one
> restricted to subproject maintainers. Or something.
Well, for now, I'd say keep the status quo of just using -hackers ...