VRChat SDK 3.1.11 doesn't follow Semantic Versioning.
closed
anatawa12
VRChat SDK Worlds 3.1.11 should be VRChat SDK Worlds 3.2.0 according to Semantic Versioning.
According to VCC docs, VRChat SDK follows Semantic Versioning 2.0.0.
According to Semantic Versioning 2.0.0 rule 7, minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API.
In VRChat SDK Worlds 3.1.11, VRChat introduced five features: load remote images/strings, play back MIDI data, simulation time access, and OnDeserialization with DeserializationResult.
This is new, backwards compatible functionality of UDON API, which is part of Public API, so VRChat must increment minor version in 3.1.11 so it should be 3.2.0.
I think it's not required to increment minor version of new UI feature is added (e.g. udon graph editor improvements in 3.1.9) because UI may not be a part of the public API.
However I think addition to UDON API is new functionality to the public API so VRChat should increment minor version.
Log In
Momo the Monster
marked this post as
closed
We've just published an update describing our current versioning system (Branding.Breaking.Bumps): https://vcc.docs.vrchat.com/vpm/packages#brandingbreakingbumps
anatawa12
Since the latest Developer Update announced new versioning for VRCSDK, I think this canny is completely outdated so, MomoTheMonster , Could you close this canny? Thank you for considering my suggestion!
anatawa12
VRCSDK 3.2.1 breaks compatibility with dlls depends on Newtonsoft.JSON. (for example, resolver 0.1.19 is incompatible with 3.2.1 as VRChat notices)
I think this is also a breaking change.
Smash-ter
so that can explain why we only see SDK 3.1.11 as the newest version instead of SDK 3.1.13 which is the latest version
anatawa12
Smash-ter: It's a known bug of VCC and will be fixed in 2.1.0. you can see this message by momo on the VRChat official discord and issue on github.
Smash-ter
anatawa12: Hope they'll also fix the project sorting order
anatawa12
VRCSDK 3.1.12 contains breaking changes to
VRCPhysBoneBase.allowCollision
, VRCPhysBoneBase.allowGrabbing
and , VRCPhysBoneBase.allowPosing
. If type of any public field is changed, it's breaking changes.According to semantic versioning, you
MUST
increment major version if there's breaking changes. So, 3.1.12 (or 3.1.13) MUST be 4.0.0 if VRCSDK follows Semantic Versioning.However, I think VRChat do want to keep VRCSDK in
3.x.x
for branding reasons so I have one suggestion: use modified Semantic versioning.Because VCC internally uses semver.net, we must use
x.y.z
form of version. So, my suggestion is to use y
of x.y.z
as major version, which will be incremented on the breaking changes and z
as minor.The worst point of current versioning is mismatch between declared versioning and actual versioning. If you declare to use modified semantic versioning like I suggested above, tools can use version form like
3.1.x
as version range for VRChat SDK to avoid breaking changes.Sayamame
anatawa12: I have noticed one additional thing.
> For example, we use the format "3.1.x" in many of the official templates and VRC SDK packages. This range will match the highest version available for 'x', without upgrading to a version like "3.2.0" in case there's some new functionality there.
However, (as explained by anatawa12) the 3.1.12 update of the VRCSDK completely ignores this and breaks compatibility with 3.1.x, as some tools (which were following the correct specification in prior to 3.1.12) do not work in 3.1.x.
These are completely self-contradictory and weaken the benefits of VPM.
Docteh
"Notice us Semverpai" 🤣