+1 We need to adjust the enforcer rule then with regards to message (to mention that it needs to be set explicitly) and also the regex (to allow 2x versions): https://github.com/apache/sling-parent/blob/0bf3676a221c6beea001bea876ca9e50156f5858/sling-parent/pom.xml#L281-L285
Konrad > On 7. Sep 2024, at 12:12, Robert Munteanu <romb...@apache.org> wrote: > > Hi, > > We have a support for different Java versions in the parent pom, > controlled by the sling.java.version property. This property can be > overridden by child modules. > > As the parent pom evolves, we sometimes change the sling.java.version, > I observed at least: > > - parent pom 26: Java 6 > - parent pom 32: Java 7 > - parent pom 35: Java 8 > - parent pom 50: Java 11 > > I think it's completely fine to evolve and require new java versions > where it makes sense. At the same time, when upgrading the parent pom > it's not obvious that this sometimes comes in with a Java version > requirement change. > > Upgrading the required Java version should (IMO) come with a minor > version bump to indicate the more strict requirements. Historically, > that has been hard to implement because the upgraded requirements > coming with the parent pom are largely invisible. > > I am thinking about whether it makes sense to remove the default > version for sling.java.version from the parent pom and then requiring > each module to set it. This will be a one-time, one-line change for > modules that require it but will make the requirement explicit. > > Thoughts? > > Thanks, > Robert
