I’d like to make the 1.3.0 and 1.4.0 releases as described. Anything after that is up for debate still.
> On Feb 14, 2023, at 3:36 PM, Volkan Yazıcı <vol...@yazi.ci> wrote: > > But then what is the resolution? > Keep on sticking to Kotlin 1.3 for now? > > On Tue, Feb 14, 2023 at 10:23 PM Matt Sicker <m...@musigma.org> wrote: > >> 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. >>>> >> >>
