Re: [Dbutil] Java 8 -> 11

There's no rule that you have to change the package name and Maven coordinates with a major version bump. As long as the API is compatible, it's OK to keep those. But breaking compatibility with Java 8 is a pretty big step forward. The goal is to allow people to produce and accept bug fixes in

Re: [Text] Java 21 failure with a double

You can always test the java version and adjust the asserts but, without being a [text] expert, I assume the toString usage will create more troubles than helping so can need to be dropped or totally embraced in the main impl. Another option is to request if the JDK dev want to fix it since it as

Re: [Text] Java 21 failure with a double

Good find Roman, that suspiciously looks like the culprit and causes a mismatch with the tests use of DecimalFormatter. Do you see a way to make the test take this into account? Ty, Gary On Sun, Oct 15, 2023, 2:13 PM Romain Manni-Bucau wrote: > Hi Gary, > > Can't it be > >

Re: [Text] Java 21 failure with a double

Hi Gary, Can't it be https://github.com/openjdk/jdk/commit/fb605944b5b734c8b47a9122e7ab3d3dcf55f71e ? Long story short, commons-text uses Double.toString which changed due to double (resp float) precision so it impacts tests. Romain Manni-Bucau @rmannibucau |

[Text] Java 21 failure with a double

Hi all, Can someone explain the 1 test failure on Java 21 in DoubleFornatTest? A one digit difference? Gary

Re: [Dbutil] Java 8 -> 11

Having a new major version for everything is not going to help I'm afraid. A major new version does not imply a Java platform change. The Maven tooling is missing a feature to the display dependency updates goal that let's you specify a maximum Java version, or maybe that exists but i doubt it.

Re: [Dbutil] Java 8 -> 11

As a consumer, I would prefer all java version changes to be considered major breaking changes for all apache commons components. I've waste lots of hours trying to find the oldest released version that supports a specific java version as the project can't yet upgrade for various reasons. On

Re: [Dbutil] Java 8 -> 11

On Sun, 15 Oct 2023 at 15:37, Elric wrote: > > On 15/10/2023 16:31, Gary Gregory wrote: > > A major version bump is rather heavy handed when no one is asking for a > > "real" 2.0 with breaking changes. > > Agreed. My 2 cents: a minor version and a clear release note is plenty. > Critical bug

Re: [Dbutil] Java 8 -> 11

On 15/10/2023 16:31, Gary Gregory wrote: A major version bump is rather heavy handed when no one is asking for a "real" 2.0 with breaking changes. Agreed. My 2 cents: a minor version and a clear release note is plenty. Critical bug fixes can still be made by bumping the patch version,

Re: [Dbutil] Java 8 -> 11

A major version bump is rather heavy handed when no one is asking for a "real" 2.0 with breaking changes. A major bump would imply a package name and Maven coordinate change. At least that's what we have done before for major version changes. We've also done major version changes without those

Re: [Dbutil] Java 8 -> 11

Not a library I use so I don't have a horse in the race. However, I do recommend making this a major version bump to 2.0 so as not to close off the possibility of critical fixes for folks still on older JDKs. On Sun, Oct 15, 2023 at 8:42 AM Gary Gregory wrote: > > We've recently released DBUtils

[Dbutil] Java 8 -> 11

We've recently released DBUtils after a long period of inactivity. Java 21 is also out. I plan on raising the floor for this component to Java 11 and GitHub builds will keep testing on Java LTS 11, 17, 21. I've not seen any Java 21 issues yet. Gary