There are quite a few jars out there that use "-jre8" type of postfixes strings in artifact IDs, so we should do the same IMO.
But... The first question to ask is whether or not we should go through the pain of even supporting different Kotlin platforms. I wouldn't bother if it were me, but I'm not a Kotlin user. Gary On Tue, Feb 14, 2023, 14:43 Volkan Yazıcı <vol...@yazi.ci> wrote: > *[I would steal the releasing infra from `log4j-tools` > <https://github.com/apache/logging-log4j-tools/blob/master/RELEASING.adoc> > for > the best speed pill.]* > > Matt, I think matching major and minor versions of `log4j-api-kotlin` with > Kotlin is a recipe for disaster. > > Imagine we shipped 1.7.0 and 1.8.0 to with Kotlin 1.7 and 1.8 support, > respectively. You just developed a new feature that you want to release > both for Kotlin 1.8 and 1.7. Are you going to release 1.9.0 for Kotlin 1.8 > users (since this is what you should be doing according to semver) and > 1.7.1 for Kotlin 1.7 users (which violates semver, since this isn't a > patch/fix). > > One can address these concerns by suffixing versions (e.g., > `1.3.0-kotlin1.8`) or providing classifiers in the dependencies, etc. But > you know what... That is not what we do. > > Do we ship different <Log4j-or-any-Java-lib> for each Java version out > there? You simply pick a good enough baseline and stick to that. Log4j > 2.x.x moved from Java 6 to 7, and then to 8; Log4j 3.0.0 will target Java > 11. > > I would simply stick to Kotlin 1.3 in our current 1.2.x line and state in > the website we support Kotlin 1.x. If Kotlin happens to introduce a version > (e.g., Kotlin 2.0) that breaks the compatibility for us, we can either > release `log4j-api-kotlin20` or `log4j-api-kotlin` 2.0.0 supporting Kotlin > 2.x, etc. > > > On Tue, Feb 14, 2023 at 6:20 PM Matt Sicker <m...@musigma.org> wrote: > > > After having migrated the build to use the new system Volkan put together > > for the main repo, I’ve managed to get the build there working in a > similar > > streamlined fashion. Thus, it’ll be a lot easier to cut some releases > > there, and wow do we have a backlog of them to get through! So here’s > what > > I’m proposing for releases: > > > > * 1.3.0 - next release. This includes a few API updates, cleaned up > > website, dependency updates, etc. 1.3.x will be the last version to > support > > Kotlin 1.3 (for context, Kotlin is at version 1.8.10 at the moment). > > * 1.4.0 - This release will bump the Kotlin version requirement to 1.4.x. > > While backward compatibility seems to stretch back to 1.3.x., this does > > make it harder to use as a dependency since we need to use a > provided-scope > > dependency to avoid using the wrong Kotlin version in an application. > Thus, > > this will be the start of some catch-up releases to pull the baseline > > Kotlin version required up to a more reasonably modern version. Amusingly > > enough, these version numbers coincide with Kotlin itself, so it’s > possible > > to make 1.5.0 require Kotlin 1.5, 1.6.0 require Kotlin 1.6, and so forth. > > * 1.5.0 - Kotlin 1.5 > > * 1.6.0 - Kotlin 1.6 > > etc. > > > > The 1.3.0 and 1.4.0 releases are the more immediately relevant ones (as > in > > I’d like to do them in a couple weeks). Since Spinnaker has been stuck on > > Kotlin 1.4 for a while, I didn’t exactly have a pressing need to move > > toward the bleeding edge, but even that project is working through > > dependency updates which will eventually get to Java and Kotlin upgrades, > > so I’d also like to release some later versions before then as well. > > > > Anything else desired for these releases? The Kotlin releases/roadmap are > > on https://kotlinlang.org/docs/releases.html which may help discover any > > new APIs or features that would be relevant to support or use. >
