I agree with Bruce. I think we are in good shape for 7.2. As long as
there is an active developer community working on maintaining and
upgrading the code base there shouldn't be problems.
Once we get the jdbc.postgresql.org website updated then there can be an
official place to post patches/updated drivers on a more frequent
schedule than the server patch releases if necessary.
Although realistically the same level of control/caution should be used
in accepting patches into the current release as there is being used for
the rest of the product (i.e. it needs to be a high priority bug and a
low risk fix to risk destabilizing a production set of code). Even in
7.1 there were some jdbc fixes that made it into 7.1.2, and quite
frankly I haven't seen anything since 7.1.2 that I would have considered
a candidate for patching into 7.1.3 based on the criteria I feel should
be applied. The 7.1.2 driver is IMHO high quality, and I use it in
production environments.
Part of the problem I see is a too frequent habit of telling users on
this list who are having problems simply to get the latest code from the
truck. We should instead be telling them to get the latest released
code ie. 7.1.2 or 7.1.3.
thanks,
--Barry
Bruce Momjian wrote:
>>* Barry Lind <barry@xythos.com> wrote:
>>|
>>|
>>| Now having said that, there isn't any reason that the jdbc code can't
>>| be released more frequently than the server. But without a lot more
>>
>>Maybe there could be sub releases or something, e.g. jdbc version 7.1.2_004
>>begin release number 4 of the JDBC driver for 7.1.2. We can't keep
>>recommending people to use CVS tip and if we cannot release a quality
>>version of the driver synchronized with the release of the core server, then
>>we will need another release cycle.
>>
>
> 7.1.X was an aberation for jdbc because Peter Mount was unavailable and
> we didn't have jdbc people working on it yet. Let's see how 7.2 and 7.3
> go with jdbc.
>
>