Another release is the simplest solution. Updating a release on Maven Central should be done in only the most exceptional condtion. This isn't one of them IMO.
Gary On Sat, Jun 6, 2026, 08:49 Oleg Kalnichevski <[email protected]> wrote: > On Fri, 2026-06-05 at 21:03 +0200, Arturo Bernal wrote: > > Hi Oleg > > > > Thank you for checking this and sorry about the broken artifacts. > > > > You are right. The artifacts were compiled to Java 1.8 bytecode, but > > apparently against a newer JDK API, so the resulting binaries are not > > actually Java 8 runtime compatible. > > > > I will double-check my Maven toolchain configuration and rebuild with > > a > > real Java 8 toolchain, then verify the produced artifacts by running > > the > > relevant tests on a Java 8 runtime before publishing anything else. > > > > Since the artifacts are already in Maven Central and cannot be > > replaced, I > > assume the right fix is to cut a corrected follow-up release, most > > likely > > 5.5-beta2, unless you prefer a different versioning approach. > > > > Sorry again for the trouble. > > > > Arturo > > > > Hi Arturo > > No trouble, but more work. In a perfect world we should be able just to > regenerate the binary artifacts. They are just release byproducts > afterall. But in practical terms it may be much easier just to cut a > new release version. > > You may want to take a look at HTTPCLIENT-2423 first. > > https://issues.apache.org/jira/browse/HTTPCLIENT-2423 > > Oleg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
