3 ms·

Easily solved, as we're free to attach any internal versioning scheme: 2016-01-01T11:51:10+00#R#+Feature#(Semver 13.0) 2016-01-07T10:50:21+00#R#Fix#(Semver

by xjay 11y ago

Easily solved, as we're free to attach any internal versioning scheme: 2016-01-01T11:51:10+00#R#+Feature#(Semver 13.0) 2016-01-07T10:50:21+00#R#Fix#(Semver 13.1) 2016-02-11T09:31:44+00#R#-Feature#(Semver 15.0) 2016-02-20T10:20:51+00#R#Fix#(Semver 15.1) (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.

untog 11y ago
Parsing that seems non trivial. If you really cared dates you could just do: 1.2016.2.20
- xjay 11y ago
  What's difficult about it? ISO 8601 is an established format. It's better to differentiate a new format from the old, common build number formats w.x.y.z. One of the tags could also contain the file name, or other context within []. Syntax: $Version:YYYY-MM-DDThh:mm:ss+00#Tag#(Custom)#[Context] Minimum: $Version:YYYY-MM-DDThh:mm:ss+00 Minimum with your own version: $Version:YYYY-MM-DDThh:mm:ss+00#(a.b.c.d) 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.
  - untog 11y ago
    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?

by xjay 11y ago

untog 11y ago

Parsing that seems non trivial. If you really cared dates you could just do: 1.2016.2.20

xjay 11y ago
What's difficult about it? ISO 8601 is an established format. It's better to differentiate a new format from the old, common build number formats w.x.y.z. One of the tags could also contain the file name, or other context within []. Syntax: $Version:YYYY-MM-DDThh:mm:ss+00#Tag#(Custom)#[Context] Minimum: $Version:YYYY-MM-DDThh:mm:ss+00 Minimum with your own version: $Version:YYYY-MM-DDThh:mm:ss+00#(a.b.c.d) 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.
- untog 11y ago
  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?