Update changelog for kotlinx-metadata-jvm 0.6.0, add migration guide, and actualize ReadMe.md
Document releasing process
Co-authored-by: Alexander Udalov <Alexander.Udalov@jetbrains.com>
Merge-request: KT-MR-8206
Merged-by: Leonid Startsev <leonid.startsev@jetbrains.com>
They were added in e4702bf438 and a08cf59017 but in fact they are not
needed on JVM until there are JVM-specific extensions in the metadata.
Moreover, there was a typo in JvmValueParameterExtensionVisitor's
superclass (see https://github.com/JetBrains/kotlin/pull/4613).
The main reason for this change is that the current API for class
version requirements (`KmClass.versionRequirements`) makes it impossible
to support pre-1.4 metadata where this was stored incorrectly for nested
classes: with the "version requirement table" in the outer class, and
indexes into that table in nested classes. See KT-41011.
Other than this aspect, metadata of classes is basically the same in
pre-1.4 and 1.4, which means that if some kotlinx-metadata-jvm users
really need to serialize metadata of an earlier version and they don't
care about the version requirements issue, they can just use these new
bytes but write the earlier version (e.g. 1.1) to the class file.
Everything will work the same, except for the possible version
requirements issue mentioned above.
Note that metadata version 1.4 is still supported for
`KotlinModuleMetadata.Writer` though.
#KT-41011 Fixed
Since the only use case of KmExtensionType in user code is checking if
it equals some other KmExtensionType instance, we'd like to hide as much
of its implementation details as possible, in case we want to change it
in the future
Otherwise this code behaves incorrectly on getter-only properties: it
returns a meaningless field signature whereas the property has no field.
It's hard to come up with an example of when this could matter in
compiler code, but it's very noticeable in kotlinx-metadata-jvm
#KT-26188 Fixed
By default, ServiceLoader.load uses thread context class loader, which
can differ from the MetadataExtensions' class loader (which also loads
JvmMetadataExtensions, since they're in the same .jar) in many cases,
for example when used in annotation processing
#KT-24881 Fixed
Leonid Startsev