Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feedback - Version ID of Steamworks SDK #662

Open
JamesMcGhee opened this issue Nov 30, 2024 · 0 comments
Open

Feedback - Version ID of Steamworks SDK #662

JamesMcGhee opened this issue Nov 30, 2024 · 0 comments

Comments

@JamesMcGhee
Copy link
Contributor

JamesMcGhee commented Nov 30, 2024

It would be nice if you added a definition letting us know which version of Steamworks SDK was being used

I say a definition so we can use it in preprocess checks
We did this in our Unreal version of the toolkit we author and its proved useful

In reality in Unity it wouldn't be a script define it would be making sure you are diligent about your use of the version field in package.manifest and that it expresses the Steamworks SDK version.

We haven't had need of something like this with Steamworks.NET as 99.9% use the latest however with things like the SteamDeck issues and all some have been rolling back and sometimes that means features are missing like Timeline

so it would be great if we could test for this with #if ... now the issues
So C# isn't quite as flexible with define as C++ but Unity has a nice feature with its assembly define versions

In a Unity Assembly Definitions, we can define our own "defines" based on the specific version of an assembly from Unity Package Manager
image
So ...
if you used a simple structured version system that mapped to Valve's version system we could use this to create our own defines that let us know what version of Steamworks.NET was present and we could do this for every version

Example

if your version system was

[Steamworks SDK Major] . [Steamworks SDK Minor] . [Your Build ID]

Then the number would be unique, it would tell us which build from you and the major and minor being from Steamworks directly means we could say

image

So if your version was for example 1.60.20251

This is the 1st build you released in 2025 for Steamworks SDK 1.60 that would be awesome

Problem & Its Workaround

so there is a bit of a problem
You currently use [Year].[build]
this means your current version will always appear larger than any new version and this will cause some hell

Unfortunately ... but understandably Unity's version system assumes 3 part sequential versions ... so how do we work around that?

image
Unity helps us out here a little bit
We can use Define constraints and version expressions to call out versions that fall within a range

This expression says that X (the current version) is greater than 1.60 but is less than 2024.8 (which is today is your latest)

This of course will require that you are diligent about updating the package.manifest with the version of Steamworks SDK that is being targeted

Why not use minor.build for Steam and let major be yours?

Because we really dont care about your build ID that is useful for you and may be useful in some ad hoc cases however the core importance is Steam works ... if you really need more than 1 field then I purpose merging Steam's major and minor into major

160.2024.8

I dont think this works as well as my prior proposition which was to keep Steam's major.minor and treat your build as ... well the build

1.60.20248

The only issue here is that your current version uses year as the major so it does mean that for the next while (couple years) devs like us would need to express a range so we can cull out the older 2024.x versions e.g. [1.60,2024.8] after a few years we could "probably" stop doing this as the number of people that would have a version from you that is that old is small and at that point it would be better to handle them in support than it would be to clutter the version expression

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant