comprehensive versioning

[dvzrv]

Hi! I would like to package vst3sdk for Arch Linux.

I'm currently a little confused by the tag schema in use. It seems to be vstsdk<major>_<day>_<month>_<year>_build_<build_number> (or maybe vstsdk3<major>_<day>_<month>_<year>_build_<build_number>).

Unfortunately that is very non-standard and also does not at all sort sanely: e.g. the last two versions only accidentally sort properly and if you had released the latest version one day later, the 2nd to last version would still be sorted as the last one!

This is easily observable by:

git ls-remote --tags --refs https://github.com/steinbergmedia/vst3sdk/ |awk '{print $(NF)}'

Additionally there is one tag that even breaks the assumed schema.

As background: For tagging purposes it does not make sense to a) use prefixes (e.g. vstsdk) unless there are multiple pieces of software developed in the same repository and should be tracked by different prefixes. A prefix in this case denotes nothing. b) use dates in Gregorian (DMY) format, because only Gregorian (YMD) format sorts properly c) use in-house build numbers (e.g. build_116), because they are only relevant to the in-house build system. If the build system gets reset or changed the build numbers will be reset as well. Build numbers have zero value to outside consumers of source code of a software project.

I propose a switch to something more comprehensive and standardized, such as semver or calver.

For packaging purposes I require a version that increases and a tag/ release name standard that increases and is parseable. The current tags account for 4(!) necessary manual interventions to update to the next version and ignoring one release.

Switching to semver would be as easy as adding additional tags for the already existing tags on the respective commits, e.g.:

vstsdk367_03_03_2017_build_352 -> 67 or 367 vstsdk368_08_11_2017_build_121 -> 68 or 368 vstsdk3612_03_12_2018_build_67 -> ? (maybe 69 or 369?) vstsdk370_30_07_2020_build_115 -> 70 or 370 vstsdk370_31_07_2020_build_116 -> ? (maybe 71 or 371?)

As is, I am completely unsure what the latest release is supposed to resolve to: 370, 370.2020.07.31, 70 or 70.2020.07.31?

[dvzrv]

As is, I am completely unsure what the latest release is supposed to resolve to: 370, 370.2020.07.31, 70 or 70.2020.07.31?

To answer my own question (more or less): I just realized, that the README states a 3.7.x, so the current version is probably 3.7.0. Unfortunately that is even worse than my assumptions above, because this assumes a-priori knowledge about how to split a string (370 in this case) and where to insert dots (.) additional to the other mentioned manual interventions.

I would highly appreciate a switch to a proper versioning scheme!

[dvzrv]

@ygrabit @scheffle could you comment on this? :)

[scheffle]

We have updated the last release tag to be "v3.7.0_build_115" and will continue to use this scheme in the future.