Such versioning number scheme is silly, many digits to remember and type correctly instead of a simple integer (major version) and a minor number (for fixes, several may be only abandoned betas or tests like 5.1, 5.3, with odd minor numbers, while stable builds would have even numbers like 5.0, 5.2, 5.4)
This is much easier to track, you don't need extra labels for alpha/beta/tests/candidates. Long term support should have a plain major version, incremented from the last major and minor numbr on which it was built and approved, while some minor version may continue on the previous minor version until it converges to a branch added to the new major LTS version. At one point the previous major is stopped (except minor fixes), new developments are made on the new major. So development branches can resist with development ported in several major versions if they are possible. You only need to track a small active set of major version numbers (some majors may have their development stopped while keeping it active for some older but important majors that have an active community supporting it and testing the "backports"; backports should use the same minor version as the origin major.minor froim which it was backported, and in that case should have a third and fourth version and odd/even number for their own tests and fixes, so that it is easy to see what was backported or not from another major): 5.4.6.2 would just mean that this is a backport of *some* features from stable 6.2 into the 5.4 stable branch (e.g. security or compatibility fixes that should not break the old branch but would allow it to continue working propertly)
Version number based on dates should not be used: we never know when something will be released, some releases may be late even if it was scheduled for some year, or season, and backports may be added years after. The number of active "LTD" branches may increase or may be reduced over time, depending on available communities working on them (not all would be tracked by
lua.org itself, this could come from a user group and announced in this list: if it is active,
lua.org may add some links to their own support pages working on older branches.
Only for specific subbranches you can add an extra third number if it's specific to a target system; if the target is a generic platform, just append the label and version number of the target such as 5.4-x86-1.0 or 5.4-win-7.1, which would come after 5.2-x86-1.0 or
5.2-win-7.1
for the same platform for which it was ported with extra patches included to correctly adapt to the target, but these labels can be ignored in Lua scripts that would only see 5.4 as their version, while the version object would have a separate property for the target platform.
So four numbers in versions is enough, scripts will only be concerned by the 2 first (major.minor) and most of them only the major (this will avoid costly tests for specific individual features: a stable branch would have a well defined set of features which will remain even if some of them are deprecated and using a new feature part of the new major is considered "preferable": lua developers can still choose which feature best fits their needs).
