Re: [Dbutil] Java 8 -> 11
This sounds a lot like what was discussed back when components went through Java 6 -> 7 and later Java 7 -> 8 upgrades. So far, we’ve only made Java requirement updates in the minor version, not the patch version, and as Gary is saying, we wouldn’t bump the major version without renaming the entire API/ABI as usual, and that’s typically reserved for compatibility-breaking changes. On the other hand, since multi-release jars are a thing, we could theoretically target Java 8 and others at the same time. Various tooling has historically been buggy around multi-release jars (anything scanning for .class files in /META-INF is already incorrect before considering multi-release jars), so that’s something to also consider. > On Oct 15, 2023, at 3:36 PM, Elliotte Rusty Harold wrote: > > 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 > libraries without being forced to upgrade to a JDK version they might > not actually need, or even be actively prohibited from using. JDK 8 > --> 9+ is a huge shift, much bigger than 7 --> 8, that breaks a lot of > projects in unexpected ways. > > On Sun, Oct 15, 2023 at 2:32 PM Gary Gregory wrote: >> >> 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 >> types of changes BUT it would be nice to be consistent. For example, to >> update to Java 11 for Commons Lang without a package name change would mean >> calling it 4.0 while the package stays as lang3, confusing. >> >> Gary >> >> On Sun, Oct 15, 2023, 9:17 AM Elliotte Rusty Harold >> wrote: >> >>> 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 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 >>> >>> >>> >>> -- >>> Elliotte Rusty Harold >>> elh...@ibiblio.org >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> > > > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
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 libraries without being forced to upgrade to a JDK version they might not actually need, or even be actively prohibited from using. JDK 8 --> 9+ is a huge shift, much bigger than 7 --> 8, that breaks a lot of projects in unexpected ways. On Sun, Oct 15, 2023 at 2:32 PM Gary Gregory wrote: > > 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 > types of changes BUT it would be nice to be consistent. For example, to > update to Java 11 for Commons Lang without a package name change would mean > calling it 4.0 while the package stays as lang3, confusing. > > Gary > > On Sun, Oct 15, 2023, 9:17 AM Elliotte Rusty Harold > wrote: > > > 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 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 > > > > > > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.org > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
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. Even with that imaginary feature, tooling would not be bullet-proof since a jar can contain a mix of class files with different byte code version. On top of that, you also have the mess Java made with multi-release jars where jars, by design, contain classes file of different byte code versions. All of that to say that you can't tool your way to building a dependency tree automatically. Gary On Sun, Oct 15, 2023, 10:59 AM John Patrick wrote: > 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 Sun, 15 Oct 2023 at 15:49, sebb wrote: > > > 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 fixes can still be made by bumping the patch version, > > > > Are you sure about that ? > > Has that been tried? > > > > > though given that Java 8 is nearly ten years old, it's really time for > > > folks to upgrade. > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > >
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 Sun, 15 Oct 2023 at 15:49, sebb wrote: > 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 fixes can still be made by bumping the patch version, > > Are you sure about that ? > Has that been tried? > > > though given that Java 8 is nearly ten years old, it's really time for > > folks to upgrade. > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
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 fixes can still be made by bumping the patch version, Are you sure about that ? Has that been tried? > though given that Java 8 is nearly ten years old, it's really time for > folks to upgrade. > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
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, though given that Java 8 is nearly ten years old, it's really time for folks to upgrade. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
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 types of changes BUT it would be nice to be consistent. For example, to update to Java 11 for Commons Lang without a package name change would mean calling it 4.0 while the package stays as lang3, confusing. Gary On Sun, Oct 15, 2023, 9:17 AM Elliotte Rusty Harold wrote: > 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 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 > > > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
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 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 -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[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
