On Fri, Mar 7, 2014 at 5:12 PM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> It would be good to do such big changes as part of the next major release,
> 09.04.xxxx. But we need to start doing them earlier, and continue to do bug
> fixes for the 09.03.xxxx series at the same time. Historically, we've only
> maintained one branch of psqlodbc, the latest one. I don't think we want to
> change that, so we need to be fairly careful to not do any big behavioral
> changes to existing applications. Otherwise an application could get stuck
> on an older release. Even with that constraint, there's a lot of old cruft
> that we could safely remove and clean up.
It would be nice IMO if odbc follows a branching model similar to jdbc
or Postgres itself with stable branches dedicated to each major
release. i imagine that as long as the clean up is not really done,
such a development model is complicated because it would make
development of bug fixes on back-branches more complicated though...
> I'd suggest that you do the changes on a fork in github and keep the mailing
> list posted on how it's going, and we merge that into the main psqlodbc
> repository when it's time for the 09.04.xxxx release.
Yep, no problem. Hm... I understand that this is hard to estimate, but
I suppose that a potential target for a 09.04.X release would be once
Postgres 9.4.0 is out. Thoughts?
> If you create new test cases, those should work with the current codebase as
> well, so we can merge those into the master branch earlier. So please post
> those separately to the mailing list as you go.
Sure.
--
Michael