Well, the version numbers don’t have to actually match; that’s more of an amusing coincidence at the moment. But anyways, this basically needs a baseline version of Kotlin; there haven’t been any backward-incompatible changes that would require supporting multiple versions like in Scala.
> On Feb 14, 2023, at 2:08 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > > 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. >>
