Btw, didn’t you consider to improve file naming?
There are currently three issues:
Version number dots are omitted
, so we have 3613 instead of 3.6.13. There is no point in omitting dots in file names (e.g. dotless filenames are not safer unlike e.g. the space character that requires percent encoding in URLs), while such omission leads to ambiguity such as whether 3613 means 3.6.13 or 36.1.3.
The order of date parts does not correspond to international date format
(YYYY-MM-DD) and therefore not a subject for correct alpha-numeric ordering
in particular. Yes, VST SDK files are typically
ordered correctly thanks to the preceding version number. BUT there were, for example, at least three 3.6.5 builds:
So depending of the day number of each release, incorrect order is possible. As we can see, the 12_11_2015 (November 2015) is before 28_08_2015 (August 2015) just because 12 is lower than 28 while 11 is actually higher than 08, so build 67 should be after 66, not before.
3. Build number is after the date
instead of after the version number. So either build number is unneeded in file name or it’d be more logical to place it immediately after version number.
So it would probably make sense to use more clear, informative and properly-sortable names like this:
It would also make sense to consider using 7-Zip
instead of Zip because 7-Zip provides much better compression while having cross-platform support. For example, the latest 3.6.13 Zip archive has the size of 85.2 MB
while 7-Zip one is just 58.5 MB
which is 1/3 smaller