Use ISO 8601, and add whatever flags you need, and establish some minimum standard vocabulary the AI can search for. :>
Development #D:
"2016-02-16T15:17:32+00#D#API"
Release #R:
"2016-02-19T17:37:21+00#R#API"
Now anything can look for dates to figure out the age of whatever it is that's running on the system, and maybe even warn about it, disable it, exploit it, etc.
(AmigaOS encouraged a $VER: prefix you could scan for, IIRC.)
If you still want a custom numbering scheme, just append it to the version string somewhere:
#API could mean there was a change to the API. Review your dependencies.
#+API could mean a function was added, but the existing API is stable. (Unless #API was also added separately, in which case a review of the change log is needed.)
#-API could mean a function was removed. Review your dependencies.
From look at your examples, I'd say what's wrong is that they are very difficult to read.
At a very brief glance I didn't notice the change between 16 and 19, and my eyes were drawn to the time, which let's face it, is probably next to useless.
And it also doesn't have any of the benefits of semver, like signaling breaking changes.
I'm not sure how to address your first concern (readability), because I don't have the context in which you would need to distinguish one version from another; as opposed to something presenting the versions to you, like a program, website, listing somewhere.
The format should be programmatically scanned for, and extracted, and represented in various ways; days ago, hours ago, minutes ago; sorted by newest, oldest; grouped by last three months, etc.
> And it also doesn't have any of the benefits of semver, like signaling breaking changes.
That's the function of tags. Agree on using #Fix for a corrective release, #Feature for a feature release, and whatever else makes sense. Ideally, there would be a minimum, standard vocabulary that makes sense.
That requires looking at every version in-between to know if a version contains breaking changes from the version I'm coming from. With semver I know that if I'm on 13.x and the latest release is 15.x, that there are potentially breaking changes. I also know that if I'm on 13.1, then 13.6 should be compatible. With your scheme, I would have to inspect the 5 versions in between to see what they were tagged with.
(I'm prefixing it with Semver because it's defined.)
This scheme is mainly about making the date and time an intergral part of a versioning format, which in turn makes it easy for machines to figure out the age of components, and automate checks.
Perhaps tags could then help add more information.
So just search for "$Version:" across multiple platforms; text files/scripts, videos, pictures, executables, etc.
Problems: Text encoding. A search may have to cover all variants. UTF-LE, UTF-BE, UTF-8, etc, but if written in isolation, it should be UTF-8.
There could be established standards for where to store such information, to optimize lookup for specific data formats.
The +00 is to emphasize UTC time (which all of these datestamps are stored as).
I suspect some people find it too verbose to use dates, but that's irrelevant; this is the minimum amount of information required for a more general versioning scheme, in my opinion.
In the course of this thread you've proposed at least six slightly different variations of the concept - what do you think are the chances of getting everyone to agree to just one of them?
Use ISO 8601, and add whatever flags you need, and establish some minimum standard vocabulary the AI can search for. :>
Now anything can look for dates to figure out the age of whatever it is that's running on the system, and maybe even warn about it, disable it, exploit it, etc.(AmigaOS encouraged a $VER: prefix you could scan for, IIRC.)
If you still want a custom numbering scheme, just append it to the version string somewhere:
#API could mean there was a change to the API. Review your dependencies.#+API could mean a function was added, but the existing API is stable. (Unless #API was also added separately, in which case a review of the change log is needed.)
#-API could mean a function was removed. Review your dependencies.
..or whatever the syntax would be.