Replies: 4 comments
-
|
I don't mind what we use at build time. Latest LTS sounds sensible enough. I thought we were going with 11 for the new baseline. If we want to drop back down to 8 again then there's some more work to do. Would you be happy to move this until after the Selenium upgrade? I'm optimistic we can get rid of the custom CI image and I think that would make this task easier. |
Beta Was this translation helpful? Give feedback.
-
|
The latest version of Selenium that supports Java 8 is 4.12.0, so that would be the maximum version we could build/test with. We are just squeaking the Selenium Manager here (which arrived in 4.11.0), but I'm wondering if a UI testing framework should care more about building and testing against newer Selenium than it should a decade old version of Java. |
Beta Was this translation helpful? Give feedback.
-
Hm, fair point, @Poundex. While Selenium isn't an API-level dependency of Geb (so users can update Selenium without needing a Geb update), I suppose there is a de facto dependency on Java version if we want to update the version of Selenium we use. I think we can just go with 11 as the baseline for the next release. For my context, we could go as high as 17 and it wouldn't create any conflicts, so I'm not worried for my end. I also agree that keeping up to date with the latest Selenium is more important. That has impacts on browser compatibility. With aggressive updates from evergreen browsers and W3C Bidi it makes more sense to focus forward than backward. Consumers can always either:
Let's stick with 11 as the new baseline for now (i.e. our target of work for the next release). So, for as succinct a compatibility strategy as we can muster, it could be "We strive to be ABI compatible with the latest Selenium version, latest Groovy version, and latest (non-milestone) Spock at release time. We will set our target Java compatibility according to the lowest version supported by both." Does that work? |
Beta Was this translation helpful? Give feedback.
-
|
That sounds good to me. I tried the 4.12.1 version of Selenium on the Geb build and instantly ran into problems with Selenium Manager. There are bugs in older versions to do with fetching Chrome and its driver if there are any local versions of each installed. Probably wouldn't have mattered in CI where's there's a blank canvas, but would have been a grim local dev experience if couldn't run some of the tests at all. |
Beta Was this translation helpful? Give feedback.
-
There are a couple of questions to address around which Java version we use in the project.
First, which Java version should we use in our pipeline? My vote is for the latest LTS of Eclipse Temurin (as of this writing, 21.0.5+11-LTS). We can update periodically for patch versions, and plan to switch to Java 25 next year when it comes out.
The second question (and more important) is which version we want to set our source and target compatibility to. This will dictate both what language features we can use in Java code and which version of Java our users must use at a minimum.
The most conservative path would be "keep compiling down to 1.8 until it is finally, completely dead." A good heuristic for that would be whenever Eclipse stops offering security patches for the Temurin release in November 2026.
While I don't like holding back from using the latest & greatest, there are some benefits to users of the library. Projects can get stuck on old versions of Java for reasons beyond their control, while still being able to update dependencies. If we don't have a compelling need for Java 21 language features, why force them to upgrade? After all, Groovy is most of our codebase, and they often backport new language features to older versions of the JVM!
Speaking of Groovy, the 5.0 alpha requires JVM 11 with invoke-dynamic (indy), https://groovy.apache.org/download.html#requirements, so it would probably be okay for us to say "We will support the minimum version of whatever Groovy supports. We will strive to have a release compatible with the latest version of Groovy shortly after their release."
To put this whole policy in a succinct form, it would be "Recent toolchains at buildtime, wide compatibility matching the latest major Groovy release."
I want to avoid getting into the business of maintaining old branches for even older compatibility and backporting things. If folks really need that, they can fork or volunteer to take on that work.
What do my fellow maintainers think? @sdelamo @Poundex ?
Beta Was this translation helpful? Give feedback.
All reactions