[dbcp] Next

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

[dbcp] Next

garydgregory
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
Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] Next

Mark Thomas
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 appreciate that this
requirement is likely to be in place for several years (4 to 5 is my
best guess) which may be longer than the DBCP community is prepared to
accept.

What is driving the desire to move to Java 8?

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] Next

Matt Sicker
On 16 June 2018 at 14:11, Mark Thomas <[hidden email]> 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 support for Java 7
without significant compensation which is not why I volunteer time for
Apache. It's also getting harder over time to even find a proper Java 7
install for various operating systems (just look at prior versions to 7 to
see where it's going).


--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] Next

Mark Thomas
On 16/06/18 21:14, Matt Sicker wrote:
> On 16 June 2018 at 14:11, Mark Thomas <[hidden email]> 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?

As I said, Tomcat 8 which has at least another 4 to 5 years of life in
it, depends on DBCP 2 and has a specification mandated requirement to
maintain compatibility with Java 7.

There are ways the Tomcat community could work around this. Because Java
7 is EOL does not - on its own - strike me as a sufficiently good reason
to create hassle for another ASF community.

If there are new features in Java 8 we want to take advantage of or an
update to the JDBC API that we want to support then fair enough. Those
are good reasons but I'd like to see them explicitly articulated.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] Next

Matt Sicker
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 <[hidden email]> wrote:

> On 16/06/18 21:14, Matt Sicker wrote:
> > On 16 June 2018 at 14:11, Mark Thomas <[hidden email]> 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?
>
> As I said, Tomcat 8 which has at least another 4 to 5 years of life in
> it, depends on DBCP 2 and has a specification mandated requirement to
> maintain compatibility with Java 7.
>
> There are ways the Tomcat community could work around this. Because Java
> 7 is EOL does not - on its own - strike me as a sufficiently good reason
> to create hassle for another ASF community.
>
> If there are new features in Java 8 we want to take advantage of or an
> update to the JDBC API that we want to support then fair enough. Those
> are good reasons but I'd like to see them explicitly articulated.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] Next

garydgregory
In reply to this post by Mark Thomas
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 am sure there is nothing stopping anyone at Apache to keep patches coming
to the DBCP 2.4.x line. I plan on keeping the release train going for many
Commons component, so I am happy to release DBCP at will.

You will notice that
https://commons.apache.org/proper/commons-dbcp/download_dbcp.cgi presents
no less than tree different versions of DBCP for different antique Java
platforms. We are just going to make that list one deeper.

Again, patches are more than welcome. And do feel free to call for a RC or
RM it yourself ;-)

Gary


On Sat, Jun 16, 2018 at 2:34 PM Mark Thomas <[hidden email]> wrote:

> On 16/06/18 21:14, Matt Sicker wrote:
> > On 16 June 2018 at 14:11, Mark Thomas <[hidden email]> 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?
>
> As I said, Tomcat 8 which has at least another 4 to 5 years of life in
> it, depends on DBCP 2 and has a specification mandated requirement to
> maintain compatibility with Java 7.
>
> There are ways the Tomcat community could work around this. Because Java
> 7 is EOL does not - on its own - strike me as a sufficiently good reason
> to create hassle for another ASF community.
>
> If there are new features in Java 8 we want to take advantage of or an
> update to the JDBC API that we want to support then fair enough. Those
> are good reasons but I'd like to see them explicitly articulated.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] Next

Claude Warren
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 should be 3.0.0 but would agree that
2.5.0 might be appropriate.   I guess the questions are:

When the versions of the software the library is dependent upon have major
version changes should the library itself have major version number changes?
Is a change in java version a major version change to a library this
library is dependent upon?

Claude


On Sat, Jun 16, 2018 at 9:41 PM, Gary Gregory <[hidden email]>
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 set of handcuffs you want to live with, then by all
> means ;-)
>
> I am sure there is nothing stopping anyone at Apache to keep patches coming
> to the DBCP 2.4.x line. I plan on keeping the release train going for many
> Commons component, so I am happy to release DBCP at will.
>
> You will notice that
> https://commons.apache.org/proper/commons-dbcp/download_dbcp.cgi presents
> no less than tree different versions of DBCP for different antique Java
> platforms. We are just going to make that list one deeper.
>
> Again, patches are more than welcome. And do feel free to call for a RC or
> RM it yourself ;-)
>
> Gary
>
>
> On Sat, Jun 16, 2018 at 2:34 PM Mark Thomas <[hidden email]> wrote:
>
> > On 16/06/18 21:14, Matt Sicker wrote:
> > > On 16 June 2018 at 14:11, Mark Thomas <[hidden email]> 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?
> >
> > As I said, Tomcat 8 which has at least another 4 to 5 years of life in
> > it, depends on DBCP 2 and has a specification mandated requirement to
> > maintain compatibility with Java 7.
> >
> > There are ways the Tomcat community could work around this. Because Java
> > 7 is EOL does not - on its own - strike me as a sufficiently good reason
> > to create hassle for another ASF community.
> >
> > If there are new features in Java 8 we want to take advantage of or an
> > update to the JDBC API that we want to support then fair enough. Those
> > are good reasons but I'd like to see them explicitly articulated.
> >
> > Mark
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>



--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] Next

garydgregory
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 <[hidden email]> 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 should be 3.0.0 but would agree that
> 2.5.0 might be appropriate.   I guess the questions are:
>
> When the versions of the software the library is dependent upon have major
> version changes should the library itself have major version number
> changes?
> Is a change in java version a major version change to a library this
> library is dependent upon?
>
> Claude
>
>
> On Sat, Jun 16, 2018 at 9:41 PM, Gary Gregory <[hidden email]>
> 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 set of handcuffs you want to live with, then by all
> > means ;-)
> >
> > I am sure there is nothing stopping anyone at Apache to keep patches
> coming
> > to the DBCP 2.4.x line. I plan on keeping the release train going for
> many
> > Commons component, so I am happy to release DBCP at will.
> >
> > You will notice that
> > https://commons.apache.org/proper/commons-dbcp/download_dbcp.cgi
> presents
> > no less than tree different versions of DBCP for different antique Java
> > platforms. We are just going to make that list one deeper.
> >
> > Again, patches are more than welcome. And do feel free to call for a RC
> or
> > RM it yourself ;-)
> >
> > Gary
> >
> >
> > On Sat, Jun 16, 2018 at 2:34 PM Mark Thomas <[hidden email]> wrote:
> >
> > > On 16/06/18 21:14, Matt Sicker wrote:
> > > > On 16 June 2018 at 14:11, Mark Thomas <[hidden email]> 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?
> > >
> > > As I said, Tomcat 8 which has at least another 4 to 5 years of life in
> > > it, depends on DBCP 2 and has a specification mandated requirement to
> > > maintain compatibility with Java 7.
> > >
> > > There are ways the Tomcat community could work around this. Because
> Java
> > > 7 is EOL does not - on its own - strike me as a sufficiently good
> reason
> > > to create hassle for another ASF community.
> > >
> > > If there are new features in Java 8 we want to take advantage of or an
> > > update to the JDBC API that we want to support then fair enough. Those
> > > are good reasons but I'd like to see them explicitly articulated.
> > >
> > > Mark
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
>
>
>
> --
> I like: Like Like - The likeliest place on the web
> <http://like-like.xenei.com>
> LinkedIn: http://www.linkedin.com/in/claudewarren
>
Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] Next

sebb-2-2
In reply to this post by garydgregory
On 16 June 2018 at 22:41, Gary Gregory <[hidden email]> 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 set of handcuffs you want to live with, then by all
> means ;-)
>
> I am sure there is nothing stopping anyone at Apache to keep patches coming
> to the DBCP 2.4.x line. I plan on keeping the release train going for many
> Commons component, so I am happy to release DBCP at will.
>
> You will notice that
> https://commons.apache.org/proper/commons-dbcp/download_dbcp.cgi presents
> no less than tree different versions of DBCP for different antique Java
> platforms. We are just going to make that list one deeper.

I think we can now drop support for JDBC 3 and JDBC 4 (Java 6)
That leaves only JDBC 4.1 (Java 7.0) as a current release.

Is that really too much to continue to support?

> Again, patches are more than welcome. And do feel free to call for a RC or
> RM it yourself ;-)
>
> Gary
>
>
> On Sat, Jun 16, 2018 at 2:34 PM Mark Thomas <[hidden email]> wrote:
>
>> On 16/06/18 21:14, Matt Sicker wrote:
>> > On 16 June 2018 at 14:11, Mark Thomas <[hidden email]> 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?
>>
>> As I said, Tomcat 8 which has at least another 4 to 5 years of life in
>> it, depends on DBCP 2 and has a specification mandated requirement to
>> maintain compatibility with Java 7.
>>
>> There are ways the Tomcat community could work around this. Because Java
>> 7 is EOL does not - on its own - strike me as a sufficiently good reason
>> to create hassle for another ASF community.
>>
>> If there are new features in Java 8 we want to take advantage of or an
>> update to the JDBC API that we want to support then fair enough. Those
>> are good reasons but I'd like to see them explicitly articulated.
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] Next

Matt Sicker
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 07:58, sebb <[hidden email]> wrote:

> On 16 June 2018 at 22:41, Gary Gregory <[hidden email]> 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 set of handcuffs you want to live with, then by all
> > means ;-)
> >
> > I am sure there is nothing stopping anyone at Apache to keep patches
> coming
> > to the DBCP 2.4.x line. I plan on keeping the release train going for
> many
> > Commons component, so I am happy to release DBCP at will.
> >
> > You will notice that
> > https://commons.apache.org/proper/commons-dbcp/download_dbcp.cgi
> presents
> > no less than tree different versions of DBCP for different antique Java
> > platforms. We are just going to make that list one deeper.
>
> I think we can now drop support for JDBC 3 and JDBC 4 (Java 6)
> That leaves only JDBC 4.1 (Java 7.0) as a current release.
>
> Is that really too much to continue to support?
>
> > Again, patches are more than welcome. And do feel free to call for a RC
> or
> > RM it yourself ;-)
> >
> > Gary
> >
> >
> > On Sat, Jun 16, 2018 at 2:34 PM Mark Thomas <[hidden email]> wrote:
> >
> >> On 16/06/18 21:14, Matt Sicker wrote:
> >> > On 16 June 2018 at 14:11, Mark Thomas <[hidden email]> 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?
> >>
> >> As I said, Tomcat 8 which has at least another 4 to 5 years of life in
> >> it, depends on DBCP 2 and has a specification mandated requirement to
> >> maintain compatibility with Java 7.
> >>
> >> There are ways the Tomcat community could work around this. Because Java
> >> 7 is EOL does not - on its own - strike me as a sufficiently good reason
> >> to create hassle for another ASF community.
> >>
> >> If there are new features in Java 8 we want to take advantage of or an
> >> update to the JDBC API that we want to support then fair enough. Those
> >> are good reasons but I'd like to see them explicitly articulated.
> >>
> >> Mark
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] Next

Rob Tompkins


> On Jun 17, 2018, at 12:38 PM, Matt Sicker <[hidden email]> 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 process would need to be streamlined and backported.
>

That’s what was running through my mind yesterday when I was reading the discussion.

-Rob

>> On 17 June 2018 at 07:58, sebb <[hidden email]> wrote:
>>
>>> On 16 June 2018 at 22:41, Gary Gregory <[hidden email]> 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 set of handcuffs you want to live with, then by all
>>> means ;-)
>>>
>>> I am sure there is nothing stopping anyone at Apache to keep patches
>> coming
>>> to the DBCP 2.4.x line. I plan on keeping the release train going for
>> many
>>> Commons component, so I am happy to release DBCP at will.
>>>
>>> You will notice that
>>> https://commons.apache.org/proper/commons-dbcp/download_dbcp.cgi
>> presents
>>> no less than tree different versions of DBCP for different antique Java
>>> platforms. We are just going to make that list one deeper.
>>
>> I think we can now drop support for JDBC 3 and JDBC 4 (Java 6)
>> That leaves only JDBC 4.1 (Java 7.0) as a current release.
>>
>> Is that really too much to continue to support?
>>
>>> Again, patches are more than welcome. And do feel free to call for a RC
>> or
>>> RM it yourself ;-)
>>>
>>> Gary
>>>
>>>
>>>> On Sat, Jun 16, 2018 at 2:34 PM Mark Thomas <[hidden email]> wrote:
>>>>
>>>>> On 16/06/18 21:14, Matt Sicker wrote:
>>>>>> On 16 June 2018 at 14:11, Mark Thomas <[hidden email]> 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?
>>>>
>>>> As I said, Tomcat 8 which has at least another 4 to 5 years of life in
>>>> it, depends on DBCP 2 and has a specification mandated requirement to
>>>> maintain compatibility with Java 7.
>>>>
>>>> There are ways the Tomcat community could work around this. Because Java
>>>> 7 is EOL does not - on its own - strike me as a sufficiently good reason
>>>> to create hassle for another ASF community.
>>>>
>>>> If there are new features in Java 8 we want to take advantage of or an
>>>> update to the JDBC API that we want to support then fair enough. Those
>>>> are good reasons but I'd like to see them explicitly articulated.
>>>>
>>>> Mark
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> --
> Matt Sicker <[hidden email]>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] Next

garydgregory
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 <[hidden email]> wrote:

>
>
> > On Jun 17, 2018, at 12:38 PM, Matt Sicker <[hidden email]> 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 process would need to be streamlined and backported.
> >
>
> That’s what was running through my mind yesterday when I was reading the
> discussion.
>
> -Rob
>
> >> On 17 June 2018 at 07:58, sebb <[hidden email]> wrote:
> >>
> >>> On 16 June 2018 at 22:41, Gary Gregory <[hidden email]> 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 set of handcuffs you want to live with, then by
> all
> >>> means ;-)
> >>>
> >>> I am sure there is nothing stopping anyone at Apache to keep patches
> >> coming
> >>> to the DBCP 2.4.x line. I plan on keeping the release train going for
> >> many
> >>> Commons component, so I am happy to release DBCP at will.
> >>>
> >>> You will notice that
> >>> https://commons.apache.org/proper/commons-dbcp/download_dbcp.cgi
> >> presents
> >>> no less than tree different versions of DBCP for different antique Java
> >>> platforms. We are just going to make that list one deeper.
> >>
> >> I think we can now drop support for JDBC 3 and JDBC 4 (Java 6)
> >> That leaves only JDBC 4.1 (Java 7.0) as a current release.
> >>
> >> Is that really too much to continue to support?
> >>
> >>> Again, patches are more than welcome. And do feel free to call for a RC
> >> or
> >>> RM it yourself ;-)
> >>>
> >>> Gary
> >>>
> >>>
> >>>> On Sat, Jun 16, 2018 at 2:34 PM Mark Thomas <[hidden email]> wrote:
> >>>>
> >>>>> On 16/06/18 21:14, Matt Sicker wrote:
> >>>>>> On 16 June 2018 at 14:11, Mark Thomas <[hidden email]> 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?
> >>>>
> >>>> As I said, Tomcat 8 which has at least another 4 to 5 years of life in
> >>>> it, depends on DBCP 2 and has a specification mandated requirement to
> >>>> maintain compatibility with Java 7.
> >>>>
> >>>> There are ways the Tomcat community could work around this. Because
> Java
> >>>> 7 is EOL does not - on its own - strike me as a sufficiently good
> reason
> >>>> to create hassle for another ASF community.
> >>>>
> >>>> If there are new features in Java 8 we want to take advantage of or an
> >>>> update to the JDBC API that we want to support then fair enough. Those
> >>>> are good reasons but I'd like to see them explicitly articulated.
> >>>>
> >>>> Mark
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: [hidden email]
> >>>> For additional commands, e-mail: [hidden email]
> >>>>
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >
> >
> > --
> > Matt Sicker <[hidden email]>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] Next

garydgregory
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 <[hidden email]> 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.
>
> Gary
>
> On Sun, Jun 17, 2018, 11:06 Rob Tompkins <[hidden email]> wrote:
>
>>
>>
>> > On Jun 17, 2018, at 12:38 PM, Matt Sicker <[hidden email]> 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 process would need to be streamlined and backported.
>> >
>>
>> That’s what was running through my mind yesterday when I was reading the
>> discussion.
>>
>> -Rob
>>
>> >> On 17 June 2018 at 07:58, sebb <[hidden email]> wrote:
>> >>
>> >>> On 16 June 2018 at 22:41, Gary Gregory <[hidden email]>
>> 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 set of handcuffs you want to live with, then by
>> all
>> >>> means ;-)
>> >>>
>> >>> I am sure there is nothing stopping anyone at Apache to keep patches
>> >> coming
>> >>> to the DBCP 2.4.x line. I plan on keeping the release train going for
>> >> many
>> >>> Commons component, so I am happy to release DBCP at will.
>> >>>
>> >>> You will notice that
>> >>> https://commons.apache.org/proper/commons-dbcp/download_dbcp.cgi
>> >> presents
>> >>> no less than tree different versions of DBCP for different antique
>> Java
>> >>> platforms. We are just going to make that list one deeper.
>> >>
>> >> I think we can now drop support for JDBC 3 and JDBC 4 (Java 6)
>> >> That leaves only JDBC 4.1 (Java 7.0) as a current release.
>> >>
>> >> Is that really too much to continue to support?
>> >>
>> >>> Again, patches are more than welcome. And do feel free to call for a
>> RC
>> >> or
>> >>> RM it yourself ;-)
>> >>>
>> >>> Gary
>> >>>
>> >>>
>> >>>> On Sat, Jun 16, 2018 at 2:34 PM Mark Thomas <[hidden email]>
>> wrote:
>> >>>>
>> >>>>> On 16/06/18 21:14, Matt Sicker wrote:
>> >>>>>> On 16 June 2018 at 14:11, Mark Thomas <[hidden email]> 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?
>> >>>>
>> >>>> As I said, Tomcat 8 which has at least another 4 to 5 years of life
>> in
>> >>>> it, depends on DBCP 2 and has a specification mandated requirement to
>> >>>> maintain compatibility with Java 7.
>> >>>>
>> >>>> There are ways the Tomcat community could work around this. Because
>> Java
>> >>>> 7 is EOL does not - on its own - strike me as a sufficiently good
>> reason
>> >>>> to create hassle for another ASF community.
>> >>>>
>> >>>> If there are new features in Java 8 we want to take advantage of or
>> an
>> >>>> update to the JDBC API that we want to support then fair enough.
>> Those
>> >>>> are good reasons but I'd like to see them explicitly articulated.
>> >>>>
>> >>>> Mark
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: [hidden email]
>> >>>> For additional commands, e-mail: [hidden email]
>> >>>>
>> >>>>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>> >>
>> >
>> >
>> > --
>> > Matt Sicker <[hidden email]>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] Next

jochen-2
In reply to this post by garydgregory
On Sun, Jun 17, 2018 at 2:42 PM Gary Gregory <[hidden email]> 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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] Next

Matt Sicker
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 <[hidden email]> wrote:

> On Sun, Jun 17, 2018 at 2:42 PM Gary Gregory <[hidden email]>
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] Next

garydgregory
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 <[hidden email]> wrote:

> 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 <[hidden email]>
> wrote:
>
> > On Sun, Jun 17, 2018 at 2:42 PM Gary Gregory <[hidden email]>
> > 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
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> Matt Sicker <[hidden email]>
>
Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] Next

garydgregory
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 <[hidden email]> wrote:

> 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 <[hidden email]> wrote:
>
>> 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 <[hidden email]>
>> wrote:
>>
>> > On Sun, Jun 17, 2018 at 2:42 PM Gary Gregory <[hidden email]>
>> > 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
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>> >
>>
>>
>> --
>> Matt Sicker <[hidden email]>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] Next

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 <[hidden email]> wrote:

> 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 <[hidden email]>
> wrote:
>
> > 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 <[hidden email]> wrote:
> >
> >> 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 <[hidden email]>
> >> wrote:
> >>
> >> > On Sun, Jun 17, 2018 at 2:42 PM Gary Gregory <[hidden email]>
> >> > 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
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: [hidden email]
> >> > For additional commands, e-mail: [hidden email]
> >> >
> >> >
> >>
> >>
> >> --
> >> Matt Sicker <[hidden email]>
> >>
> >
>



--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [dbcp] Next

Pascal Schumacher
+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 <[hidden email]> wrote:
>
>> 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 <[hidden email]>
>> wrote:
>>
>>> 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 <[hidden email]> wrote:
>>>
>>>> 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 <[hidden email]>
>>>> wrote:
>>>>
>>>>> On Sun, Jun 17, 2018 at 2:42 PM Gary Gregory <[hidden email]>
>>>>> 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
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>> --
>>>> Matt Sicker <[hidden email]>
>>>>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]