Release Scheduling

[lyxal]

The old way of versioning/release making was horribly unorganised and completely subjective - there wasn't really much rhyme or reason as to how releases were made. Hence, I want to propose a set of objective guidelines for incrementing version numbers.

Why is This Important?

This is mostly for objectively specifying what version of the web interpreter is being used - currently, if someone asked you "what version of vyxal is the online interpreter running?", you'd have to find the specific commit that is being used, as it isn't using any specific version. (The answer is that it's running some amount of commits after v2.4.1 but before v2.5). This is a result of the website always using the latest commit rather than the latest defined version.

v2.x.y will always look nicer than something like 97a728aca8e9e776287307bf730e732388fc7985.

Version Release Format

Major.Minor.Patch.Subpatch

(subpatch is discussed further down)

The Actual Schedule

Weekly Releases

These would be releases made every week if there was a significant amount of commits (i.e. more than 1) were pushed to Vyxal during that week. The patch number of the version would be incremented - the next weekly release after v2.6.1 would be v2.6.2. Alternatively, a subpatch number could be introduced - the next weekly release after v2.6.1 would be v2.6.1.1 and then v2.6.1.2 and so on.

If no code changing commits are made in a week (i.e there's no commits at all or only documentation changes), then obviously there'd be no need for a weekly release in that week.

Fortnightly Releases

These would take precedence over weekly releases if enough commits were pushed in a fortnight to justify incrementing the minor number of the version. For example, if a major wave of bugs were found and patched, you might increment v2.6.1 to v2.7 instead of v2.6.2. More specifically, if 75% (percentage subject to change) of Vyxal answers written in the old version have to be changed to remain valid, the minor version number should be incremented.

If no code changing commits are made in a fortnight (i.e there's no commits at all or only documentation changes), then obviously there'd be no need for a fortnightly release in that fortnight.

Monthly Releases

If the minor version number hasn't been incremented by the end of the month, a release incrementing the minor version number should be made. This way, there's at least one minor version per month to reference.

If no code changing commits are made in a month (i.e there's no commits at all or only documentation changes), then obviously there'd be no need for a monthly release in that month.

Summary

This schedule is purely a set of guidelines and is highly subject to change (based on feedback, practicality, etc). If there's a need to override this process, that's perfectly fine.

[razetime]

Might be simple to use semantic versioning: https://semver.org/

[lyxal]

This is more about the frequencies of releases not how versioning should work though