Formalise release versions

[monkeyman192]

Currently the versions that are released are a bit of a mess. This is due to a number of reasons, but primarily because the naming convention that was chosen a while back was based on how we were able to decide the particular release was done, and this no longer applies as we are able to know with a very high degree of certainty that we have mapped out all the classes.

Currently we do the following: All verisons are structured like X.YY.Z.W (where the X.YY.Z corresponds to a NMS version number and the a is the "pre-release" version of the program (ie. 3.74.0.1 corresponds to v3.74.0-pre1) This is confusing as, once all the classes have been successfully mapped out, it no longer makes sense to call the release a "pre-release", and so the pre in the version is misleading.

I propose that we do the following instead:

• We formalise the concept of a "pre-release" by only ever making these a "pre-release" in the strict term of github releases. These will be in cases where an update has just come out and not all the classes have been mapped out yet, so we know that the release is not complete. These "pre-release" versions will be given a tag of vX.YY.Z-preW to indicate a pre-release and will be released as such.
• Once a release is deemed "not-pre-release" it will be tagged vX.YY.Z.W.
• In the above situation W will continue to be incremented over pre-releases until the proper release is hit (ie. the releases may look like v3.74.0-pre1, v3.74.0.pre2, v3.74.0.3, where this last release is NOT a pre-release and is instead a full release.

I am not particularly set on the above idea and would love some feedback on it. We must keep in mind that we already have a system in place to write the version to the mbin file, so if we were to make drastic changes we'd need to create a new schema for the MBIN file header which will be a decent amount of work.

[cmkushnir]

I'd just stick to your first point - "formalise the concept of a "pre-release" by only ever making these a "pre-release" in the strict term of github releases" and stop there. I'd get rid of the "pre" from all tags and just use "vX.YY.Z.W" for all. Don't think should rename tags ever, instead simply use github and uncheck the pre-release box if it's ready for GA (if for some reason it was originally marked as a pre-release, but not sure if this would ever happen as you know if all struct's have been updated when you create release).

[monkeyman192]

I'd just stick to your first point - "formalise the concept of a "pre-release" by only ever making these a "pre-release" in the strict term of github releases" and stop there. I'd get rid of the "pre" from all tags and just use "vX.YY.Z.W" for all. Don't think should rename tags ever, instead simply use github and uncheck the pre-release box if it's ready for GA (if for some reason it was originally marked as a pre-release, but not sure if this would ever happen as you know if all struct's have been updated when you create release).

Yeah, this makes sense. The one slight issue is that there will be less autonomy as whether the release is released as a pre-release or not can be handled by the CI, but if we are going to be doing both then it may be harder to know if the release should be a pre-release or not automatically. Having the pre in the version would fix this as we could check for it. However there may be another way, as we could make a standard so that if a commit is tagged, we also check the start of the commit message, and if it starts with [pre] then we consider it a pre-release. This way we can standardise the versioning of tags, and automate the (pre)-release-ness still. And if one forgets to add this prefix then it can easily just be changed in the releases list anyway.

[cmkushnir]

Hmm, not familiar w/ CI requirements|limits. If you need a naming convention to identify if the release should be flagged as a pre-release or not then I guess that kinda' answers the question. Either that or you have the CI always build as pre-release and someone has to manually uncheck the pre-release for GA releases.

[monkeyman192]

Hmm, not familiar w/ CI requirements|limits. If you need a naming convention to identify if the release should be flagged as a pre-release or not then I guess that kinda' answers the question. Either that or you have the CI always build as pre-release and someone has to manually uncheck the pre-release for GA releases.

I mean, I'd ideally like it to be as automated as possible. Basing it on some name would work well, but has the drawbacks you mention. However having it in the name also means that when someone downloads it they know already from the name that it's pre-release. Maybe adding an extra bit somewhere in the header which indicates that the release is a pre-release and then increment the version haha. Probably not needed that bad though!