3 ms·

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 do

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. :)
  - eqvinox 7y ago
    The fix to it coming crashing down seems to be to append another version number, at which point the date code becomes kind of a branch indicator. Now you have a choice of either incrementing the date code liberally for small releases (e.g. Twisted), or keeping it sticky until you make a major change (e.g. Teradata.) If you do the former, you're depriving the user (or chain-up developer) of information on how big a particular change was. It might be 20190322 to 20190411 but you merged a huge rewrite. Or it's 20180107 to 20190929 and it's just some fixes. You might as well give your releases alphabetically increasing codenames, same information content there. On the other hand if you keep it sticky until you make a major change, you're back to making a call whether some change is "major" or not. You might as well use SemVer. If anything, a date code in front of the version number becomes misleading since if you reach a reasonably stable API it'll start getting weirdly old and confuse users. I also find it funny (and somewhat disingenious) that you assume I never tried calendaric versioning. I use (or suggest) it whenever some project starts or otherwise (e.g. rewrite) goes through an instability period. This generally means version numbers like "0.20190811". When the instability period has passed, it moves to e.g. "1.0" and sticks with SemVer from there. If we start rewriting on top of 2.3, the version number might temporarily be e.g. "2.99.20200105". Exact numbers (and components/dot count) depends on the specific situation. It's hopefully obvious that all of these versions are something I'd call "alpha" or "internal consumption". (Also means my brain has learned prejudice to distrust any version number with a date code.) [Edited] P.S.: developers can't escape time, but code can. I recently dug up a project I last touched in 2007, and you know what? I don't even get compiler warnings. It just works. (It's obviously written in a language & ecosystem that affords this possibility — not all of them do.)

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. :)
- eqvinox 7y ago
  The fix to it coming crashing down seems to be to append another version number, at which point the date code becomes kind of a branch indicator. Now you have a choice of either incrementing the date code liberally for small releases (e.g. Twisted), or keeping it sticky until you make a major change (e.g. Teradata.) If you do the former, you're depriving the user (or chain-up developer) of information on how big a particular change was. It might be 20190322 to 20190411 but you merged a huge rewrite. Or it's 20180107 to 20190929 and it's just some fixes. You might as well give your releases alphabetically increasing codenames, same information content there. On the other hand if you keep it sticky until you make a major change, you're back to making a call whether some change is "major" or not. You might as well use SemVer. If anything, a date code in front of the version number becomes misleading since if you reach a reasonably stable API it'll start getting weirdly old and confuse users. I also find it funny (and somewhat disingenious) that you assume I never tried calendaric versioning. I use (or suggest) it whenever some project starts or otherwise (e.g. rewrite) goes through an instability period. This generally means version numbers like "0.20190811". When the instability period has passed, it moves to e.g. "1.0" and sticks with SemVer from there. If we start rewriting on top of 2.3, the version number might temporarily be e.g. "2.99.20200105". Exact numbers (and components/dot count) depends on the specific situation. It's hopefully obvious that all of these versions are something I'd call "alpha" or "internal consumption". (Also means my brain has learned prejudice to distrust any version number with a date code.) [Edited] P.S.: developers can't escape time, but code can. I recently dug up a project I last touched in 2007, and you know what? I don't even get compiler warnings. It just works. (It's obviously written in a language & ecosystem that affords this possibility — not all of them do.)