I am a maintainer on ‘Egeria’ (g: org.odpi.egeria) and considering our Java 11->17 strategy.
We publish many (100s) maven artifacts to ‘Snapshots’ as part of our merge builds, and via staging to ‘Release’ for our monthly releases. Artifacts get signed etc & it’s mostly automated other than promoting staging->release.
We do build verification/tests on Java 17 already - but don’t distribute the artifacts.
Java 17 may cause a little disruption with users of these artifacts. I was considering whether we could publish the java 17 versions to a different repository. I’m unclear if this is doable with the central repositories?
Alternatives include using other maven repositories like perhaps github, another artifactory - but that’s a little more work to the pipelines. Or another option might be to adopt different group or artifact names, but with 100s involved i’m concerned this would just be confusing and lead to clutter.
Also I know we could use classifiers, but the proposal here is for short term (3-4 months?) testing, with minimal impact to any consumers - like flipping a switch, and classifiers could get messy… We’re hoping NOT to continue building with java 11 beyond this and flip over for our next major version.
Do you intend to start using Java 17 specific APIs right away?
Do you intend to maintain support for the Java 11 ecosystem once you start using Java 17 specific APIs?
Will the next major version support Java 11 consumers?
You say “Java 17 may cause a little disruption with users of these artifacts.” Is this because they use Java 17 specific APIs or for some other reason?
Another option you haven’t listed is publishing a beta version of the next major version for the existing group, artifact coordinates. If you intend to no longer support Java 11 consumers in the next major version, then you can make your clean break with the next major version.
Not right now, but when we move to Java 17 ~1Q23 we’ll go all-in and permit use of Java 17 language constructs/APIs
No (current proposal)
No
The intent of publishing Java 17 built artifacts short term (and we already build and test, just don’t push to a repo) is to facilitate any consumers testing with the Java 17 libraries . We have a monthly release cycle so normally this would just be 4.0-SNAPSHOT … but in this case we’d like to do it over quite a few monthly releases.
‘disruption’ in part is forcing any consumers to try things out with Java 17, since our code won’t work <17 any more, and ensuring they can work with existing java 11 (even 8?) built code they also have.
Starting our next release (ie 4.0-SNAPSHOT) early is another option (- and is indeed probably the cleanest. Normally we’d just branch - though this adds a little overhead, an alternative is just to massage the version in the ci/cd. There may be some confusion from having a 3.x-SNAPSHOT as well as 4.x-SNAPSHOT but that’s just communication.
On balance, I’m more inclined to go with just starting the release early since everything is already in place for this - it’s entirely normal part of the process, just something we usually only have for a short period (month) vs many months, and only one at a time – so thanks for that suggestion!