Re: Versioning - was JDBC 4 Compliance - Mailing list pgsql-jdbc

I'm trying to understand how changing the version number of the driver would affect all of the current users.

Firstly my posts don't see to arrive on the list - so apologies on that front. I proposed a numeric scheme, but equally something similar to what andrew has just posted would apply. I think we should have a stable version that is pretty much fixed as after all there seem to be few bugs/changes and it gives users who require stability something to use. However many people, myself included often require features from the latest spec or other functionality that isn't available and having a more up to date version would be ideal. Splitting it this way offers the best of both worlds, then at some point in the future, I envisage the unstable driving being marked as stable, the stable becoming legacy/archived and a new development version started.

There are quite a few people using the driver and suddenly moving it seems precipitous 

Do you mean moving to a versioning scheme or switching versions at some point in the future? Provided the current ones are archived and linked to on the page I would hope people are smart enough to be able to find the version they need.

On another note, I'd be happy to help out on the maintenance side of things, but think some form of guidance that you and the other committers have followed would be useful

John

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

On Mon, Jun 24, 2013 at 5:44 PM, John Lister <john.lister@kickstone.com> wrote:

I mentioned it in my previous post, but what are the lists thoughts on using a different versioning strategy for the driver in a similar manner to other OS projects.

My suggestion would be to:
- freeze the current release at v1.x for partial JDBC4 support
- archive the pre JDBC4 versions completely
- start a new version 2, for example incorporating the major NIO and XA changes previously discussed running on the current JDK incorporating stubs or complete functions for the latest JDBC spec features as needed, etc and supporting the latest versions of Postgres as appropriate

Work would progress with v2 with only significant bug fixes to then be propagated back to v1.

Hopefully this reaches some compromise for the stability issues with existing users who can remain on v1 with newer projects migrating to the v2.

At some point in the future I'd envisage a new version being released for example with the release of JDK8 or JDBC5 as required..

John