Simplifying the versioning scheme for general users

[decryptedchaos]

As i brought in discord i want to discuss the version scheme.. this is something I've come across talking to people about in the industry and some review channels in the space.. I'm often met with the response "Stride doesn't release updates fast enough that's concerning"
at first i wasn't sure why this was such a common opinion.. then it kind of struck me when I noticed it everybody is focusing only on the major/minor and very seldom the build numbers. so in this respect, it does appear to the unfamiliar that stride isn't releasing updates..

SemVer

I believe we are mostly using the SemVer scheme, but with the optional build number.

• ex. 4.1.0:1948

It's been my experience that, generally speaking, especially outside of windows / .NET programing people don't naturally process the build number. in this context, especially for an open source project, that depends on community engagement for its growth, we must take every step to make the project approachable to new users.

My understanding for the argument for the use of build numbers is that it increments regardless of major/minor/patch for every build. On paper that sounds good, however in practice for the overall userbase, I believe it's causing more confusion..

Proposal

So I propose dropping the build number for 4.2 or at least shortly after if its too close to refactor for the release. In this way going forward would follow the more standard SemVer syntax of:

• 4.2.0

And any release or patch that gets released there would increment the patch in this way

• 4.2.1
• 4.2.2

I personally prefer stopping patches at double digits because something like 4.2.50 looks strange therefore I'd personally limit patches to .10 as show below.

• 4.2.10

And then we should probably roll to a minor of 4.3.0. However this is very much open for debate, maybe .15 could look okay I just think getting too crazy with patch versions like .99 is excessive.

This is so much easier to read, and for people to understand the rate at which progress is being made, this isn't so straightforward with build numbers that also reside under the 4.1.0 tag.

I personally think this will go a long way to gaining community attention, as it will be easier to see the changes happening between patches vs minors.. This is 100% a perception thing, like i say it has been my experience that people think Stride is NOT pushing any updates because it remains on the same minor for so long from their perspective.

Thanks.

[tebjan]

That is basically what we discussed in the last contributor's meeting. We'll release minor packages more frequently where the third number will be increased per release. either monthly or bi-weekly. https://www.stride3d.net/blog/community-meeting-october-2023/#short-summary-of-contributor-meeting

However, the build number is essential for nightly builds, so the packages will probably keep them, but the launcher could be adapted somehow—just the question of who does that.

[decryptedchaos]

However, the build number is essential for nightly builds, so the packages will probably keep them, but the launcher could be adapted somehow—just the question of who does that.

Yeah I don't have a problem with them from a internal / technical standpoint, however from a forward facing end user standpoint its causing confusion in my experience.

Its not a problem that they are used per say, so maybe I should rephrase, but perhaps they shouldn't be presented to the user unless that users specifically wants a nightly build, outside of bleeding edge releases they seem to just be causing confusion..

So anything that's forward facing like the launcher shouldn't display it (unless beta/nightly is selected) the website shouldn't display it on official releases (only if there is a beta/nightly page maintained) its about the user experience not the technicality. making it as easy to understand for a wide community means a lot for the communities growth.

I was going to update the poll with Hide as an option for official release, but it would have cleared the votes and that would skew the results so let this serve as clarification. Hiding it on official builds serves the same function

[manio143]

To be technically accurate, for Stride it's not build number, but commit height (effectively the same purpose).

I kind of agree that users may not be accustomed to seeing a large 4th number. However, I'm not clear that this is causing issues. From a practical standpoint, the user opens launcher, selects latest version they see and clicks Install/Start. Unless they have to interact with the version by hand, they wouldn't be very concerned. Both launcher and any NuGet client will tell them - this is the latest version.

A different concern I would pose is that we don't utilize the Patch version at all. If we were able to increment it with every package release within the Minor, it would be more clear to the user that there's linear continuity between packages. As you mentioned, commit height is not very intuitive to compare between versions because it's a bigger number.

But ultimately it's about convenience - we manually increment version Major+Minor and let the automatic commit height be used when running the package pipeline. We would need to use a more complex tracking system with proper Patch increments.

[decryptedchaos]

I'm not clear that this is causing issues. From a practical standpoint, the user opens launcher, selects latest version they see and clicks Install/Start.

Well, we will see what impact the current slated changes have, though i personally have seen fairly skilled people in the industry tell me,

• "The problem with stride is they haven't released a minor version in over a year i think its slowly dying.."

The truth is it had releassed several interations of version 4.1.0 under different build/commit numbers. See the perception is everything if people don't take the time to learn it regardless if it is their fault for not doing so it still hurts the project in the long run.

A different concern I would pose is that we don't utilize the Patch version at all. If we were able to increment it with every package release within the Minor, it would be more clear to the user that there's linear continuity between packages. As you mentioned, commit height is not very intuitive to compare between versions because it's a bigger number.

This too is also probably my primary concern, i can see how this would potentally add complexity to releases, but i see it as a very important aspect of our sort of interface with the users if you will.. the "first impressions" aspect so to speak.