> -----Original Message-----
> From: Ludek Finstrle [mailto:luf@pzkagis.cz]
> Sent: 14 December 2005 17:04
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] Next development steps?
>
> > > 1) clean the code (and UI) with drop all non-trivial features
> > > - these features make the code unreadable and complicated with
> > > no proper behaviour right now
> > > - there is no error report for them since libpq support
> > > (exclude [#1000413] Optimistic lock cannot be used with
> > > updateable
> > > cursors - I think updateable cursor doesn't work at all)
> >
> > What features do you have in mind?
>
> All which use backend_tuples or is unreachable at least.
> I'm sorry I don't have a list. It is only my ideas based on
> what I see through patching. I also try to start cleaning code
> and I always stop becouse I go to updateable cursor implementation
> or DRIVER_CURSOR or something similar.
>
> > I'm more inclined to create a stable branch and develop in tip.
>
> I'm sorry I'm unable to translate "develop in tip".
Tip == Head (or trunk in subversion). We put all the new code in
head/tip, and keep the stable code in a separate branch.
> I think that we use current stable version as start point for
> development branch. I don't think we could share code between this
> two branches. It doesn't lead to better (readable) code.
I think that should be assessed on a per-patch basis. If there is a bug
that can be fixed in the stable branch with low risk of causing other
problems, then it should be fixed. If it's specific to the new code, or
high risk, then it should only be fixed in head.
> > Can I also assume you expect to be around for a good while
> to work on
> > this ambitious plan? ODBC developers are few and far between, so
> > starting a major project can be quite a commitment for all of us.
>
> Yes. I'm planning this mainly for me (maybe someone join me/us).
Well, it seems that the Pervasive guys are back again, and we've had
offers to help with bug hunting :-)
Regards, Dave.
