search

monkeyman192 / MBINCompiler

A tool for decompiling No Man's Sky .MBIN files to XML format
https://monkeyman192.github.io/MBINCompiler
Other
249 stars 49 forks source link

Formalise release versions #481

Open monkeyman192 opened 2 years ago

monkeyman192 commented 2 years ago

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:

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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!