4 ms·

This comes crashing down in a nice mudslide the exact moment you start maintaining an older stable release for fixes while also progressing on a newer version.

This comes crashing down in a nice mudslide the exact moment you start maintaining an older stable release for fixes while also progressing on a newer version. If anything, date codes are useful as later version number component, e.g. 4.1.0.191220. Also, the "When to use" section is getting things quite wrong: Does your project feature a large or constantly-changing scope? Large systems and frameworks, like Ubuntu and Twisted. Amorphous sets of utilities, like Boltons. Wrong question - relevant is: "is your project the top end of the dependency chain?" Is your project time-sensitive in any way? Do other external changes drive new project releases? Business requirements, such as Ubuntu's focus on support schedules. Security updates, such as certifi's need to update certificates. And both of these are actually made much harder by calendaric versioning. Administrators are already reluctant to update software for fear of breaking things. SemVer gives extremely useful information here to establish how "dangerous" and update might be. With date code versions, the admin is forced to dig through change logs, which costs time they probably don't have, so they'll just not update.

BubRoss 7y ago
Why not use two date codes, the release date and the update date?
- eqvinox 7y ago
  For starters, that's a pretty long version number, making it difficult to see at a glance what the relation is. One date (or two for comparing) is something humans are trained to handle, two dates (or four!) not so much. Also, now you just have SemVer with really large version numbers.
  - paulddraper 7y ago
    The release date portion may be abbreviated (assuming no more than one major release per month). Released 2020-04-05, updated 2020-10-15. Version: 2004.201015 I'm not in love with that, but that's how I'd assume it'd work.
mhashemi 7y ago
Why? The version number is determined by the original release date, and after that it's just a normal version number. Pretty sure the Teradata library linked does basically that. Python's manylinux standard is another example. The whole point of CalVer as an alternative is that SemVer has sold folks a bill of goods with regard to software maintenance. Perpetuating the idea that people can blindly update will always create problems. More discussion here: https://sedimental.org/designing_a_version.html https://sedimental.org/designing_a_version.html
- eqvinox 7y ago
  > Why? Why what? (I seriously don't understand what argument you're trying to make in your first paragraph.) > [...] SemVer has sold folks a bill of goods with regard to software maintenance. Perpetuating the idea that people can blindly update will always create problems. You're forgetting to ask the question whether this bill of goods is desirable. Considering the environment we have today (frequent security updates, huge dependency chains, interconnected systems), I'd say it's not just desirable but straight up necessary. People should be able to blindly update. They need to be able to, because users are not developers and updates need to be made as accessible as possible in order to propagate and proliferate as quickly as possible. What we need is better testing and release engineering to get SemVer right, not defining the problem away by ditching a layer of usability.
  - mhashemi 7y ago
    I was only asking why you say it comes crashing down, when the link cites multiple cases of successful parallel version maintenance with a version that is at least partially calendar-based. As far as usability, time is a dimension no developer can escape. We develop software on a schedule and we deprecate it on a schedule. CalVer is tremendously semantic at that higher level. The semantics SemVer clings to suffer even under ecosystems which have mandated their use (go, node). The effect has been an over-granularization of APIs themselves. I'm fine with agreeing to disagree for now. I'm also fine with the case that CalVer is not for everyone and everything. I'll leave it with this, a post seems to articulate a lot of your concerns: https://caremad.io/posts/2016/02/versioning-software/ https://caremad.io/posts/2016/02/versioning-software/ It was written in 2016 by Donald Stufft, a maintainer of pip. Today, pip has been CalVer for a while and I'm not sure anyone has looked back. Try it sometime, and you might find the same. :)
skissane 7y ago
> SemVer gives extremely useful information here to establish how "dangerous" and update might be. I'm doubtful about how useful the information SemVer gives really is. Someone can make massive changes to a package, rewrite half of it from scratch, add huge new features, completely redesign how parts of it are implemented, but if they don't making any breaking API changes the first version segment doesn't increment. On the other hand, someone removes some obscure feature which nobody ever used anyway, and that causes the first version segment to increment. The administrator should be much more worried about the first change than the second, but SemVer misleads them into being more worried about the second than the first.
- SahAssar 7y ago
  SemVer is about the public API, it says nothing about test-coverage, internal changes or transient dependencies. The point of SemVer is to answer "if I trust the authors of this library to be as good or better than me at writing libraries, is it safe to upgrade?". The moment you don't trust the authors of the library to be as good or better than you it sorta breaks apart as a covenant, but it will still show the intent of the author. So SemVer has problems, but CalVer just shows "I tagged a release at a date". IMO badly practiced SemVer is better than perfect CalVer simply because I can open an issue of fix something that was broken because of SemVer, but with CalVer I need to live with any breakages regardless of if they were intentional or not.

BubRoss 7y ago

Why not use two date codes, the release date and the update date?

eqvinox 7y ago
For starters, that's a pretty long version number, making it difficult to see at a glance what the relation is. One date (or two for comparing) is something humans are trained to handle, two dates (or four!) not so much. Also, now you just have SemVer with really large version numbers.
- paulddraper 7y ago
  The release date portion may be abbreviated (assuming no more than one major release per month). Released 2020-04-05, updated 2020-10-15. Version: 2004.201015 I'm not in love with that, but that's how I'd assume it'd work.

mhashemi 7y ago

Why? The version number is determined by the original release date, and after that it's just a normal version number. Pretty sure the Teradata library linked does basically that. Python's manylinux standard is another example. The whole point of CalVer as an alternative is that SemVer has sold folks a bill of goods with regard to software maintenance. Perpetuating the idea that people can blindly update will always create problems. More discussion here: https://sedimental.org/designing_a_version.html https://sedimental.org/designing_a_version.html

eqvinox 7y ago
> Why? Why what? (I seriously don't understand what argument you're trying to make in your first paragraph.) > [...] SemVer has sold folks a bill of goods with regard to software maintenance. Perpetuating the idea that people can blindly update will always create problems. You're forgetting to ask the question whether this bill of goods is desirable. Considering the environment we have today (frequent security updates, huge dependency chains, interconnected systems), I'd say it's not just desirable but straight up necessary. People should be able to blindly update. They need to be able to, because users are not developers and updates need to be made as accessible as possible in order to propagate and proliferate as quickly as possible. What we need is better testing and release engineering to get SemVer right, not defining the problem away by ditching a layer of usability.
- mhashemi 7y ago
  I was only asking why you say it comes crashing down, when the link cites multiple cases of successful parallel version maintenance with a version that is at least partially calendar-based. As far as usability, time is a dimension no developer can escape. We develop software on a schedule and we deprecate it on a schedule. CalVer is tremendously semantic at that higher level. The semantics SemVer clings to suffer even under ecosystems which have mandated their use (go, node). The effect has been an over-granularization of APIs themselves. I'm fine with agreeing to disagree for now. I'm also fine with the case that CalVer is not for everyone and everything. I'll leave it with this, a post seems to articulate a lot of your concerns: https://caremad.io/posts/2016/02/versioning-software/ https://caremad.io/posts/2016/02/versioning-software/ It was written in 2016 by Donald Stufft, a maintainer of pip. Today, pip has been CalVer for a while and I'm not sure anyone has looked back. Try it sometime, and you might find the same. :)

skissane 7y ago

> SemVer gives extremely useful information here to establish how "dangerous" and update might be. I'm doubtful about how useful the information SemVer gives really is. Someone can make massive changes to a package, rewrite half of it from scratch, add huge new features, completely redesign how parts of it are implemented, but if they don't making any breaking API changes the first version segment doesn't increment. On the other hand, someone removes some obscure feature which nobody ever used anyway, and that causes the first version segment to increment. The administrator should be much more worried about the first change than the second, but SemVer misleads them into being more worried about the second than the first.

SahAssar 7y ago
SemVer is about the public API, it says nothing about test-coverage, internal changes or transient dependencies. The point of SemVer is to answer "if I trust the authors of this library to be as good or better than me at writing libraries, is it safe to upgrade?". The moment you don't trust the authors of the library to be as good or better than you it sorta breaks apart as a covenant, but it will still show the intent of the author. So SemVer has problems, but CalVer just shows "I tagged a release at a date". IMO badly practiced SemVer is better than perfect CalVer simply because I can open an issue of fix something that was broken because of SemVer, but with CalVer I need to live with any breakages regardless of if they were intentional or not.