Vega-strike-engine-source: Version Schema...

[BenjamenMeyer]

We presently use the age old standard of <major>.<minor>.<patch>, and for our first release series (0.6.x) and possibly the couple others we have planned (0.7.x, 0.8.x) this might make sense to continue. However, I'd like to propose that after 0.8.x we move to a version schema like Ubuntu has used: <year>.<month>.<patch>.

Reasoning: Right now we're trying to stabilize some functionality and get things under control, so it makes sense to continue the current version schema. However, once we're moving it would be good to do move to a rolling-release style mechanism where we work on stuff for a few months, then enter a feature freeze, stabilize, and release. This style of releasing might fit using the year-based version schema better; it would also remove the concept of trying to achieve the whole 1.0.0 release.

[BenjamenMeyer]

I'm not opposed to changing to this schema for 0.8.x or even 0.7.x as that is after the 0.6.x baseline establishment.

I do not want to change it for the first release we're doing - 0.6.0 - since that is defining a baseline for us going forward and should be a minimal set of changes from the last release.

[nabaco]

I like the semantic versioning release schema that we have now. Especially since we're exposing external APIs to Assets creators, and we need to maintain compatibility accross compilers/distros/libs.
So semantic versioning gives a sense of things to all those dependant on us.

For more info: https://semver.org/

[pyramid3d]

Both make sense: indicating breaking changes with a version component, and making it more rollable.
What about VERSION.ISO8601DATE.PATCH for example

next VS release could be
0.202006.0 or 0.2020.0

where

• VERSION would be the breaking change indicator
• DATE can be year, year+month, or even year+month+day
• patch can be a day or any sequential numbering

[BenjamenMeyer]

I think it's a matter of how we apply the versioning. Ubuntu for instance has a certain sequence for the long term stability (breaking change point) - .04; things can break in between. That makes sense at the distro level. Using a numeric prefix @pyramid3d suggest might be a good method for us to do similar. I'm open to ideas.

[BenjamenMeyer]

This has implications on #441 and it's compatriot https://github.com/vegastrike/Assets-Production/issues/53, and https://github.com/vegastrike/Assets-Masters/issues/19. We need to bring those discussions all together, especially as #331 gets some implications too.

Essentially:

• we need a way to do this somewhat programatically that doesn't involve generating tons of branches for each individual release
• we need to be able validate the release versions in testing
• we need to be able to manage our pre-releases
• we want to be able to auto-generate releases using GH Actions

[BenjamenMeyer]

Something to follow https://gitlab.kitware.com/cmake/cmake/-/issues/16716