4 ms·

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;

by xjay 11y ago

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.

rajivm 11y ago
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.
- 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

rajivm 11y ago

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.

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?