Are there any risks to upgrading the Y.js version? I assume every version being a patch version means it’s fine, but I want to make sure. I have a client and server both running a pretty old version.
I assume Yjs follows semver, so all non-major version upgrades will be backwards-compatible.
For major version upgrades, you may want to consult the release notes, although not all major-version releases clearly state the breaking changes.
The changelog for old versions <13.0.0 was removed, but they can be viewed in the commit diff. Changes after v13 are document in GitHub releases.
2 Likes
@dmonad Could you weigh in on this discussion? Do you have any suggestions for coordinating yjs upgrades among clients/servers?
Can different clients use different yjs versions so long as they’re on the same major version?
For context, we’re looking to upgrade from 13.5.38 to 13.6.8.
As @raine said, Yjs follows semver. That means a feature that is new in 13.6.0 will cause issues if you run 13.5.0 (an older release) in the backend. So make sure that everyone is up-to-date before you use any new features. E.g. don’t use the “Y.Text feature that allows embeds to be Y.Maps” in 13.5.x, as it was released in 13.6.0. As long as you don’t use that feature, nothing will break. Semver.
1 Like
Is it only a matter of upgrading the central persistent host first to the newest version, or must usage of ALL new features be delayed until the LAST client has upgraded? In a big network, with many clients offline for maybe long times, this sounds a bit infeasible.