Concern about current versioning with constraints beta for future (general) open beta

[anatawa12]

Current versioning with constraints SDK beta would cause problem with open-beta SDK in the future.

problem

In current constraints beta SDK, VRCSDK 3.6.2-constraints.x is used for version name. However, this would cause problem with open beta since 3.6.2-beta.x is older version than 3.6.2-constraints.x in semver comparison method.

solution

It looks VRCSDK for avatar size limit will be released as 3.6.2 so for constraints beta for VRCSDK 3.6.3, consider using 3.6.3-alpha.constraints.x. 3.6.3-alpha.constraints.x is older version than 3.6.3-beta.x so upgrading constraints beta to general open beta does not cause problem.

[anatawa12]

[orels1]

Hey! Could you elaborate on what exactly is the issue? With beta versions, it is general practice to explicitly depend on a particular beta version instead of using any version ranges.

And considering constraints and general beta SDKs are not compatible - you wouldn't want to upgrade one to another 🤔

Edit: basically I'm failing to see how sorting one version over another is desirable, since going constraints -> open beta will nuke your constraints. I would even argue that going from 3.6.2-beta.1 to 3.6.2-constraints.2 is safer, as it doesn't break your avatar by removing newly added constraint scripts

[anatawa12]

I think it's not good to accidentally upgrade to contraint beta juat by clicking upgrade button on the VCC.

[orels1]

but wouldn't arranging them the other way - accidentally upgrade you from constraints beta to open beta and also break things?

To be completely honest, I think there should just not be an upgrade button for beta versions outside of particular beta "id"

[orels1]

E.g. if we have 3.6.2-constraints.1, 3.6.2-constraints.2 and 3.6.2-beta.1 available

• Project Version: 3.6.1 - No upgrade button visible
• Project Version: 3.6.2-constraints.1 - Upgrade to 3.6.2-constraints.2 visible
• Project Version: 3.6.2-beta.1 - No upgrade button visible

I feel like offering an "upgrade" to a pre-release from stable and across pre-release "branches" is undesired in most cases, but I will discuss it with the team

[anatawa12]

but wouldn't arranging them the other way - accidentally upgrade you from constraints beta to open beta and also break things?

I thought normal beta SDK would be available with constraints so that was no problem I thought at the time I wrote this issue.

To be completely honest, I think there should just not be an upgrade button for beta versions outside of particular beta "id"

I think it's good feature!

I think alpha versions should be easily upgradeable to beta easily and constraints-beta to normal beta should also be easy once they're merged. Therefore I hope some manifest option to allowing upgrade between channels would be excellent. But I think it's controversial if benefits outweigh complexity or not so this is not a required feature.

[orels1]

After some internal discussion, we're leaning towards avoiding upgrade prompts in the way I described above. We're hoping we can slot that work in sometime soon.

Part of this issue stems from the lack of pre-release package toggle per-project in the VCC at the moment, and the fact that VPM, currently, does not resolve pre-release versions in direct dependencies without that toggle enabled. Which in turn means many people might have the pre-release toggle enabled without really knowing what it means.

So removing upgrade button while still allowing picking the version in the dropdown is something we want to implement. Potentially with some other way of indicating that there are "newer" versions available, but without a direct upgrade prompt.

And as we also suspect that we'll have more simultaneous betas running in the future - relying purely on sorting to decide which versions are "safe" doesn't feel scalable.

[anatawa12]

After thinking a while, I now think this beta channel system should be opt-in.

many packages (including my Avatar Optimizer, bd_'s NDMF and ModularAvatar, Raina's TexTransTool) use alpha/beta/rc channel, which is good to upgrade (change channels) with semver semantics. I want VCC to not to restrict upgrade from beta to rc for my/our packages.

[orels1]

I don't think making it opt-in would be that useful, as that would essentially mean nobody uses it. At that point it might not be worth implementing such a system altogether.

The plan wasn't to restrict upgrades it was to still show that there are newer versions (with some sort of badge) without providing a direct upgrade button, asking users to be more intentional about the change, otherwise that would be unreliable for things that do not use alpha-beta-rc "magic string" approach, and cause issues as described in your initial request.

[anatawa12]

I mean refrain users from upgrade between channel by not showing upgrade button. "restrict" was not correct wording. Sorry.

Also, I mean opt-in by package author, not user. I think Package author should have control to enable/disable new "beta channel" semantics in VCC.

[orels1]

Ah! Ok sorry, I read it like it was meant to be a user-facing option. Sure, a flag like that might make sense, yeah