4 ms·

No human being, for the entirety of human history, has ever looked at v1 and thought "hmmm version one, that must mean it's a stable release!" Normal human bei

No human being, for the entirety of human history, has ever looked at v1 and thought "hmmm version one, that must mean it's a stable release!" Normal human beings look at v1 and go "yeeeeesh here we go!" All software everywhere should be versioned YYYY.MM.DD. That 0.62.3.1b-45x-fart nonsense has to go. YYYY.MM.DD If compatibility is broken VERSION THE NAME.

01HNNWZ0MV43FF 2y ago
That's SemVer except integrating the major version into the name and the patch version and minor version into the date
SahAssar 2y ago
I'm a living disproof of your comment regarding v1. Besides that time-based versioning communicates nothing besides the release time, which is basically useless for anything except perhaps a root trust store or the tzdb. 1.3.2-alpha3 gives me so much more info than 2024.08.27, even besides that fact that YYYY.MM.DD disregards that you sometimes release the same software multiple times a day. Why would you even care when the version is released? You care about compatibility and if it is secure (which needs to be tracked out of band anyway).
- snakeyjake 2y ago
  >Why would you even care when the version is released? I don't. The actual numbers, both in my example and yours, are almost irrelevant. Your example only communicates more info if you know what constitutes a major and minor release for that specific project, which (let's be real here) you don't-- hell nine times out of ten the project itself doesn't know that. And if you do, then you also know which milestones were reached or are planned for specific dates. My example sorts nicely. Looks pretty. Gives you an idea at a glance how old and busted your stuff is.
  - SahAssar 2y ago
    > I don't. The actual numbers, both in my example and yours, are almost irrelevant. So why would you make them less relevant? With semver packages that do proper versioning actually communicate something meaningful and for packages that don't do proper versioning it's just a number like in your proposal. > Your example only communicates more info if you know what constitutes a major and minor release for that specific project For semver that is defined and even if only loosely followed still gives an indication of the intention. > My example sorts nicely. Use sorting that understands the context. `sort -h` works for bash. For v0.0.0-alpha1 and similar stuff date-versioning does not help either. > Looks pretty. Subjective and not useful. > Gives you an idea at a glance how old and busted your stuff is That assumes that every library/package needs constant updates. Many packages only needs updates every couple of years. Nothing about how "busted" your stuff is is communicated. --- I still don't understand why you consider release date something that is meaningful to communicate in the version? Even if the author is wrong about compatibility 99% of the time it would still be better to use semver than date-versioning since it would still give you an indication of if the author feels the compatibility is broken. Date just says the date, which is meaningless for compatibility or features.

01HNNWZ0MV43FF 2y ago

That's SemVer except integrating the major version into the name and the patch version and minor version into the date

SahAssar 2y ago

I'm a living disproof of your comment regarding v1. Besides that time-based versioning communicates nothing besides the release time, which is basically useless for anything except perhaps a root trust store or the tzdb. 1.3.2-alpha3 gives me so much more info than 2024.08.27, even besides that fact that YYYY.MM.DD disregards that you sometimes release the same software multiple times a day. Why would you even care when the version is released? You care about compatibility and if it is secure (which needs to be tracked out of band anyway).

snakeyjake 2y ago
>Why would you even care when the version is released? I don't. The actual numbers, both in my example and yours, are almost irrelevant. Your example only communicates more info if you know what constitutes a major and minor release for that specific project, which (let's be real here) you don't-- hell nine times out of ten the project itself doesn't know that. And if you do, then you also know which milestones were reached or are planned for specific dates. My example sorts nicely. Looks pretty. Gives you an idea at a glance how old and busted your stuff is.
- SahAssar 2y ago
  > I don't. The actual numbers, both in my example and yours, are almost irrelevant. So why would you make them less relevant? With semver packages that do proper versioning actually communicate something meaningful and for packages that don't do proper versioning it's just a number like in your proposal. > Your example only communicates more info if you know what constitutes a major and minor release for that specific project For semver that is defined and even if only loosely followed still gives an indication of the intention. > My example sorts nicely. Use sorting that understands the context. `sort -h` works for bash. For v0.0.0-alpha1 and similar stuff date-versioning does not help either. > Looks pretty. Subjective and not useful. > Gives you an idea at a glance how old and busted your stuff is That assumes that every library/package needs constant updates. Many packages only needs updates every couple of years. Nothing about how "busted" your stuff is is communicated. --- I still don't understand why you consider release date something that is meaningful to communicate in the version? Even if the author is wrong about compatibility 99% of the time it would still be better to use semver than date-versioning since it would still give you an indication of if the author feels the compatibility is broken. Date just says the date, which is meaningless for compatibility or features.