5 ms·

>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 com

>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.

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.