Thanks all for the comments, created
https://issues.apache.org/jira/browse/SLING-12426 .

Thanks,
Robert

On Tue, 2024-09-10 at 13:42 +0200, Julian Sedding wrote:
> +1 - I think it makes sense to manage the version in each module's
> pom.
> 
> Regards
> Julian
> 
> On Sun, 8 Sept 2024 at 18:08, Konrad Windszus <[email protected]>
> wrote:
> > 
> > +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 <[email protected]>
> > > 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
> > 

Reply via email to