Versioning scheme for nimskull

[alaviss]

With nightlies bits coming together, we should start thinking about the compiler versioning scheme and format.

Right now I only have a versioning format proposal, which is:

<major>.<minor>.<patch>[-(pre.<commit date in yyyymmdd> | rc.<number>)[+<commit hash>]]

This is mostly inspired by semantic versioning:

• major, minor, patch: Up for debate, I personally think we can use a similar scheme to upstream, sans the "odd versions are development" rule.
• pre: This specifier is what will be used in untagged builds (nightlies). Stands for "pre-release", chosen because it is lexically smaller than rc. A version with this specifier will always be "older" than an rc version.
• rc: This specifier is for release candidates, must be tagged in the repository. A version with this specifier will always be "older" than one without it.
• +<commit hash>: Optional specifier for the commit hash, does not participate in version comparison, for informational purposes only.

Examples:

• 0.1.0 > 0.1.0-rc.1 > 0.1.0-pre.20220101
• 0.1.0-rc.1+abcdxyz == 0.1.0-rc.1+xyzdcba

[saem]

Can we make it extra dumb and simply have version numbers?

<major>.<minor>

• major is we for sure broke things
• minor is we tried not to, but run tests and hope the types save you

No RC, no LTS, none of that. If we want to do that in the future. First thing we would do is setup outside of the compiler repo versioned specification. That would run the various versions against the compiler and libs and say which it checks out against. That can flag breakages and stops the "because I changed tests along with the change" breakages or didn't really think about migration. It's the correct forcing function without burdening authors and reviewers with "being careful" all the time. Also jeans people who care about all that sort of stability bare a bunch of that burden more directly and/or it's a service to charge for.

[alaviss]

Why no RC? They are fairly useful in giving us a stabilizing window before an official release.

[saem]

Because I don't think there is anything to stabilize, we just keep releasing. We can have a separate process to mark "more stable" releases vs not. We could have a mirror repo where people can spend time trying to figure out what to mark as stable and debating those nuances.

For new features or changes let's have more tests, use the type system, correctness by design, use macros to prove things out, do research and not Iignore the wider world, make smaller low risk releases, etc. So we're not spending time and energy on trying to stabilize giant changes.

[alaviss]

So let's hold the RC stuff there.

Are we gonna have versions dedicated to "in-development" or we do use something like a suffix to distinguish them?

[saem]

I think every few commits (2-10?) and/or time (a month) passes, we should do a release.

[CyberTailor]

I'd like versioning scheme that other compilers (GCC, Clang) use