kryo: Major breaking changes while keeping the same package
reading migration guide.
the best approach is to load the old data somehow, then write it with the newer version. For example, by juggling classloaders the data could be loaded with v2, then written with v5.
I fail to see how this is the best or even a good approach. Could you please elaborate?
As far as I see it’s best practice for java libs in general to simply move to a new package for major / breaking updates like this eg. com.esotericsoftware.kryo.v5, so everybody is happy with smooth migrations.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 26 (3 by maintainers)
Commits related to this issue
- Add versioned kryo artifact (currently kryo5) This adds a completely self-contained kryo artifact that can be used together with another major kryo version at the same time. Therefore all dependenci... — committed to magro/kryo by magro 5 years ago
- Add versioned kryo artifact (currently kryo5) This adds a completely self-contained kryo artifact that can be used together with another major kryo version at the same time. Therefore all dependenci... — committed to magro/kryo by magro 5 years ago
- Move versioned artifact under group id "com.esotericsoftware.kryo" To not pollute the "com.esotericsoftware" namespace, as discussed in #650. Also changed the `Automatic-Module-Name`. — committed to magro/kryo by magro 5 years ago
- Add versioned kryo artifact (currently kryo5) (#652) * Add versioned kryo artifact (currently kryo5) This adds a completely self-contained kryo artifact that can be used together with another maj... — committed to EsotericSoftware/kryo by NathanSweet 4 years ago
I agree, in terms of simplicity just providing the versioned artifact is the better way. I’m also fine with that way.
I was referring to any consumer <= 4 intending to move to v5.
Maybe we could/should provide an additional artifact “kryo5” which comes with renamed package name. Then users could choose their tradeoff.
Technically this might be possible by adding a module depending on kryo and shading it to the v5 package.