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. > >> > >
