Hi all, I think we need to build with the next EA Java version especially when the next Java version is an LTS version like 25. This serves as an early warning signal for work to do but also as playing out part in the FOSS at large ecosystem where we should report failures to the 3rd party tooling we use.
Some other builds are experimental for released versions of Java like 24 because they are known to fail and serve as either a reminder of work to do or a warning to users. An failing experimental build is OK IMO. GH knows the difference and doesn't send a failure email if all production builds are green and an experimental build is red. All these GH CI builds show the world what we test and what to expect. If a user sees a failing experimental build we can offer it as a to do for contributions which I've done in the past. In general, I think we should build with all LTS versions plus the next EA version as experimental. Even if an EA build is green it should stay experimental since the EA behavior could be a moving target. IOW, please don't remove experimental builds. HTH, Gary On Fri, May 9, 2025, 07:44 Arnout Engelen <enge...@apache.org> wrote: > Hello Commons Dev, > > I noticed that, for many commons components, our GitHub Actions build > matrix includes building against 'experimental' JVM versions - e.g. > > https://github.com/apache/commons-logging/blob/master/.github/workflows/maven.yml#L33-L35 > . > > These builds commonly fail all the time. While I guess this is fine as > they're 'experimental', I do think it makes the new/casual-contributor > workflow worse, as they also show up as 'build failures' in PRs and it > wouldn't be entirely obvious to newcomers that they're harmless. > > I'd like to understand what these jobs are for, and see if we can find an > approach that avoids those distracting build failures? > > > Kind regards, > > -- > Arnout Engelen > ASF Security Response > Apache Pekko PMC member, ASF Member > NixOS Committer > Independent Open Source consultant >
