+1
Am 21.06.2018 um 20:33 schrieb Matt Sicker:
I'd stick with 2.x since it's still backwards compatible. Upgrading the
base Java version is not a semantic change IMO, but it shouldn't be done in
a patch release.
On 19 June 2018 at 16:48, Gary Gregory wrote:
To be clear:
DBCP 2.4.0 - Java 7
I'd stick with 2.x since it's still backwards compatible. Upgrading the
base Java version is not a semantic change IMO, but it shouldn't be done in
a patch release.
On 19 June 2018 at 16:48, Gary Gregory wrote:
> To be clear:
>
> DBCP 2.4.0 - Java 7 - JDBC 4.1 (just released)
> DBCP 2.5.0 or 3.
To be clear:
DBCP 2.4.0 - Java 7 - JDBC 4.1 (just released)
DBCP 2.5.0 or 3.0.0 - Java 8 - JDBC 4.2 (in git master)
DBCP 2.6.0 or 4.0.0 - Java 9 - JDBC 4.3 (to do)
Thoughts?
Gary
On Tue, Jun 19, 2018 at 2:28 PM Gary Gregory wrote:
> I have no API breaking changes for 3.0, so I do not s
I have no API breaking changes for 3.0, so I do not see a need for a major
version change. Feedback welcome. I am more interested in getting the next
version out to pick up the new methods from JDBC 4.2 on Java 8.
Gary
On Tue, Jun 19, 2018, 13:49 Matt Sicker wrote:
> Bumping to 3.0 could allow
Bumping to 3.0 could allow for adopting lessons from other connection pool
libraries in API incompatible ways. I have no specific examples, but
HikariCP is a general one.
On 19 June 2018 at 14:27, Jochen Wiedmann wrote:
> On Sun, Jun 17, 2018 at 2:42 PM Gary Gregory
> wrote:
>
> > 3.0.0 somewha
On Sun, Jun 17, 2018 at 2:42 PM Gary Gregory wrote:
> 3.0.0 somewhat implies API breakage which has not happened yet so 2.5.0 is
> better for now IMO...
+1 for going to 3.0.0 anyways. This would perhaps fix the problem for
Tomcat, assuming that we keep a maintenance branch for 2.x.
Jochen
Git master is now on JDBC 4.2 on Java 8.
Are we OK calling the next release 2.5.0?
Gary
On Sun, Jun 17, 2018 at 5:21 PM Gary Gregory wrote:
> Note that while I am working on getting git master up to JDBC 4.2 on Java
> 8, the current version is JDBC 4.3 on Java 9. I am only looking at 4.2.
>
>
Note that while I am working on getting git master up to JDBC 4.2 on Java
8, the current version is JDBC 4.3 on Java 9. I am only looking at 4.2.
Gary
On Sun, Jun 17, 2018, 11:06 Rob Tompkins wrote:
>
>
> > On Jun 17, 2018, at 12:38 PM, Matt Sicker wrote:
> >
> > Ideally, if we can just keep v
> On Jun 17, 2018, at 12:38 PM, Matt Sicker wrote:
>
> Ideally, if we can just keep various branches around in releasable states,
> then we can keep old dbcp 2.x.* maintenance releases moving forward. Based
> on my experiences trying to release this module before, though, I think
> that proces
Ideally, if we can just keep various branches around in releasable states,
then we can keep old dbcp 2.x.* maintenance releases moving forward. Based
on my experiences trying to release this module before, though, I think
that process would need to be streamlined and backported.
On 17 June 2018 at
On 16 June 2018 at 22:41, Gary Gregory wrote:
> Hello Mark and all,
>
> Thank you for the heads up on the Tomcat plans.
>
> Asking DBCP to stay on Java 7 for 4-5 years is insane IMO, and it certainly
> is not going to attract anyone to maintain and grow this component (IMO
> again.) If that is a s
The real question is should we change Maven coordinates and package name?
I've barely started on JDBC 4.2 and it does not seem required yet.
3.0.0 somewhat implies API breakage which has not happened yet so 2.5.0 is
better for now IMO...
Gary
On Sun, Jun 17, 2018, 04:40 Claude Warren wrote:
>
If we look at java version numbering as 1.x then the argument could be made
that each java minor version is really a new version in the semantic
numbering scheme. With this in mind then the version number for DBCP
should jump when the java version jumps.
I would argue that the java 8 version shou
Hello Mark and all,
Thank you for the heads up on the Tomcat plans.
Asking DBCP to stay on Java 7 for 4-5 years is insane IMO, and it certainly
is not going to attract anyone to maintain and grow this component (IMO
again.) If that is a set of handcuffs you want to live with, then by all
means ;-
I’m more concerned about the 4-5 year time frame given. That includes at
least two more LTS Java releases.
On Sat, Jun 16, 2018 at 15:34, Mark Thomas wrote:
> On 16/06/18 21:14, Matt Sicker wrote:
> > On 16 June 2018 at 14:11, Mark Thomas wrote:
> >
> >> What is driving the desire to move to Ja
On 16/06/18 21:14, Matt Sicker wrote:
> On 16 June 2018 at 14:11, Mark Thomas wrote:
>
>> What is driving the desire to move to Java 8?
>>
>
> What's driving the desire to maintain support for a seven year old release
> of Java which is not supported without paying large sums of money to
> Oracl
On 16 June 2018 at 14:11, Mark Thomas wrote:
> What is driving the desire to move to Java 8?
>
What's driving the desire to maintain support for a seven year old release
of Java which is not supported without paying large sums of money to
Oracle? I certainly have no interest in continuing suppor
On 16/06/18 19:19, Gary Gregory wrote:
> Now that we have 2.4.0 almost out the door, I'd like to update from Java 7
> to Java 8 and go from JDBC 4.1 to 4.2.
Tomcat 8.x uses DBCP 2 and has a specification mandated requirement to
work on Java 7.
I'd prefer it if DBCP 2 stuck to Java 7 but I appreci
Now that we have 2.4.0 almost out the door, I'd like to update from Java 7
to Java 8 and go from JDBC 4.1 to 4.2.
Gary
19 matches
Mail list logo
