v0.19.1

Compare Source

NOTE: 0.19.1 is the same as 0.19.0. There was a publishing issue preventing 0.19.0 from getting out to Central.

This release makes commit message scope suppliers more flexible.

Use of scopeSupplier = calcScopeFromCommitMessages() allowed specifying the scope with a commit message like major: My Message or patch: My message. However, there was a special case when the project hadn't reached 1.0.0 yet.

Before a project reaches 1.0.0, major: prefixes were downgraded to minor. The intent was to encourage breaking changes to still be committed as major: for consistency, but respecting that reaching 1.0.0 is a more significant decision than just the first breaking change introduced into your code.

The downside was that the only alternative to get to 1.0.0 was to use -Preckon.scope=major to supersede what the commit message supplier decided. This can be incompatible with many workflows that don't allow user interaction when reckon runs.

With this release:

• scopeSupplier = calcScopeFromCommitMessages() now additionally supports a major!: prefix which ignores whether the project is pre-1.0.0 and forces use of the major scope
• Introduces scopeSupplier = calcScopeFromCommitMessageParser(BiFunction) which allows custom logic to consider both the commit message and whether the project is pre-1.0.0 when it makes it's scope decision
• scopeSupplier = calcScopeFromCommitMessages(Function) continues to use the same pre-1.0.0 behavior when a major scope is returned for backwards compatibility

Breaking Changes

None

Enhancements

• #​205 Allow commit message scope suppliers to bump version to v1.0.0

Fixes

• Dependency updates

Deprecations

None

Compatibility

Tested against the following versions.

v1.8.0

==================

This is a release candidate for the next version. It is based on Kotlin 2.1.0 and includes a few new features, as well
as bugfixes and improvements:

@JsonIgnoreUnknownKeys annotation

Previously, only global setting JsonBuilder.ignoreUnknownKeys controlled whether Json parser would throw exception if
input contained a property that was not declared in a @Serializable class.
There were a lot of complaints that this setting is not
flexible enough.
To address them, we added new @JsonIgnoreUnknownKeys annotation that can be applied on a per-class basis.
With this annotation, it is possible to allow unknown properties for annotated classes, while
general decoding methods (such as Json.decodeFromString and others) would still reject them for everything else.
See details in the corresponding PR.

Stabilization of SerialDescriptor API and @SealedSerializationApi annotation

SerialDescriptor, SerialKind, and related API has been around for a long time and has proven itself useful.
The main reason @ExperimentalSerializationApi was on SerialDescriptor's properties is that we wanted to discourage
people from subclassing it.
Fortunately, Kotlin 2.1 provides a special mechanism for such a
case — SubclassOptInRequired.
New kotlinx.serialization.SealedSerializationApi annotation designates APIs
as public for use, but closed for implementation — the case for SerialDescriptor, which is a non-sealed interface for
technical reasons.
Now you can use most of SerialDescriptor and its builders API without the need to opt-in into experimental
serialization API.
See the PR for more details.

Note: All SerialKinds are stable API now, except PolymorphicKind — we may want to expand it in the future.

Generate Java 8's default method implementations in interfaces

TL;DR This change ensures better binary compatibility in the future for library. You should not experience any
difference from it.

kotlinx.serialization library contains a lot of interfaces with default method implementations. Historically, Kotlin
compiled a synthetic DefaultImpls class for them.
Starting from Kotlin 1.4,
it was possible to compile them using as Java 8's default methods to ensure
that new methods can still be added to interfaces without the need for implementors to recompile.
To preserve binary compatibility with existing clients, a special all-compatbility mode is supported in compiler
to generate both default methods and synthetic DefaultImpls class.

Now, kotlinx.serialization finally makes use of this all-compatibility mode,
which potentially allows us to add new methods to interfaces such as SerialDescriptor, Encoder, Decoder, etc.,
without breaking existing clients. This change is expected to have no effect on existing clients, and no action from
your side is required.
Note that Kotlin 2.2 plans to enable all-compatibility
mode by default.

Other bugfixes and improvements

• Correctly skip structures with Cbor.ignoreUnknownKeys setting (#​2873)
• Handle missing system property without NPE (#​2867)
• Fixed keeping INSTANCE field and serializer function for serializable objects in R8 full mode (#​2865)
• Correctly parse invalid numbers in JsonLiteral.long and other extensions (#​2852)
• Correctly handle serial name conflict for different classes in SerializersModule.overwriteWith (#​2856)
• Add inline reified version of encodeToString as a Json member to streamline the experience for newcomers. (#​2853)
• Do not check kind or discriminator collisions for subclasses' polymorphic serializers if Json.classDiscriminatorMode
  is set to NONE (#​2833)

v3.10.2

Compare Source

2025-01-08

• Fix: okio-nodefilesystem artifact is no longer empty.

v3.10.1

Compare Source

2025-01-07

• New: FileSystem.close() may prevent future access and/or clean up associated resources depending on the backing implementation. FakeFileSystem will prevent future operations once closed.
• InputStreams created from BufferedSource.inputStream() now have a more efficient version of InputStream.transferTo() which reduces memory copies.
• okio-nodefilesystem is no longer publised as a JS project, but a Kotlin multiplatform project with only a JS target. This change should not affect consumers in any way, and is motivated by the Kotlin Gradle plugin deprecating the JS-only plugin.

v3.10.0

Compare Source

2025-01-06

This version is equivalent to the subsequent 3.10.1, but it did not fully publish to Maven Central due to infrastructure problems.