Re: Wrong version of jdbc in 7.3.3 rpms

Lamar,

I can understand you not wanting to install the components necessary to
build the various jdbc versions.  So I would just request that you pull
the latest prebuilt version from jdbc.postgresql.org when doing a new RPM.

I will try to answer some of your other questions below.

Lamar Owen wrote:
> On Thursday 05 June 2003 11:39, Barry Lind wrote:
> 
>>Does anyone know why apparently the 7.3beta1 version of the jdbc drivers
>>are what is included in the 7.3.3 rpms?
> 
> 
>>>The pg73b1jdbc3.jar file is very old (it is the 7.3 beta 1 version).
>>>What RPMs are you using?  You should contact whoever produced those RPMs
>>>to get them built with the current version.  The 'official' version is
>>>the source code that is tagged with the 7.3.3 freeze label (which is the
>>>version that is currently posted on the jdbc.postgresql.org web site)
> 
> 
> I am whoever. :-)
> 
> I have not synced up with the version on jdbc.postgresql.org (primarily 
> because I didn't know about there being a newer version).
I understand.  In the future always just grab the latest prebuilt
version from jdbc.postgresql.org.
> 
> I do not have a JDK installed here, so I don't build the JDBC driver from 
> source.  So, I'll blame my own bit rot.  
I understand.
> 
> Since the postgresql-jdbc RPM has no dependencies and is a 
> distribution-independent RPM, I'll roll a new one.  This won't require a 
> rebuild on all the distributions supported, since we're talking distribution 
> independent jars.
> 
> However, I wouldn't mind pulling the JDBC subpackage out of the main set 
> entirely, and having a separate RPM distribution for that.  You could 
> maintain that yourself easily enough.  I can even give you a starting spec 
> file, and the JDBC driver could have a separate release schedule, which might 
> be appropriate anyway.
The topic of having jdbc on a separate release cycle has come up in the
past multiple times.  And in general I have been against it (and also
the move of the jdbc code to a separate project).

In general jdbc needs to release as often as the server.  Because jdbc
heavily depends on all the pg_* tables and they tend to change each
release, there needs to be a corresponding release of jdbc for each
server release.  Now jdbc could release on a more frequent schedule than
the server, but there currently just aren't enough developers working on
it for that to be a reality, so the current server schedule works out
just right.
There are a number of reasons that IMHO moving the source out of the
core project does not make sense for jdbc:
1) Documentation infrastructure - the server has a nice setup for
producing doc.  I don't have time or want to reinvent all that for the
jdbc doc if it were in a separate project.
2) Core developer access.  It is a great benefit when Tom, Bruce or some
other core hacker makes some sort of global change to the backend
tables, and they can change all the source affected including the jdbc
source.
3) Release infrastructure - RPMs and packageing work is already done 
(and it usually works :-)
4) Beta program - When postgres does a beta, it is great to be a part of 
that automatically.  Instead of needing to try and get the word out and 
do it on a different cycle.

> 
> Going the one obvious next step forward, is there a compelling reason to 
> include the JDBC client as part of the main tarball, rather than a separate 
> project (ODBC is separate, as is the C++ and Perl clients) (and the same 
> thing can be said for the Python client)?  Does the JDBC client need backend 
> source code, or is it happy being built with just the necessary fe protocol 
> headers? (I'm thinking out loud here -- I can see a reason for the JDBC 
> driver to have a separate release schedule from the main tarball, but I'm not 
> saying 'JDBC is a problem child!  Let's yank it because I don't want to deal 
> with it!').  
> 
> Barry, what would be your preference?  What would best serve JDBC users? 
> (other than me installing all the software necessary to build the JDBC from 
> source -- this requires non-vanilla software in the form of the JDK, as well 
> as the build environment that the makefiles want, and with me not being a 
> Java developer at this time, I wouldn't necessarily be up on what is 
> considered the 'canonical' development or runtime environments.  With the 
> other portions of PostgreSQL, nothing beyond the stock distribution is 
> required for build.)  
> 
> I think it would best serve the users for an active JDBC developer to make 
> that distribution.  Please advise how you would like to handle this.

I think I answered all of the questions put forth here.  If I haven't 
please let me know.

thanks,
--Barry

PS.  Thanks for all the work you do on the RPMs.  You provide a valuable 
service to the postgres community.

PPS. Perhaps someday you will get the beter 'upgrade' you have been 
asking for.  I think you have been asking for it for as long as I have 
been a part of the postgres community.