Re: Release plans for log4j-api-kotlin

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ı 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 wrote: >

Re: Release plans for log4j-api-kotlin

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

Re: Release plans for log4j-api-kotlin

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 F

Re: Release plans for log4j-api-kotlin

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 n

Re: Release plans for log4j-api-kotlin

*[I would steal the releasing infra from `log4j-tools` 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