Switch to a Calendar based versioning scheme

[dlamblin]

What's the problem this feature will solve?
Y2.1k a.k.a. Y2k lessons learned.

Describe the solution you'd like
If you're going to "Switch to a Calendar based versioning scheme" why would you not at least use iso 8601 order and recommendations like:
Yours , Recommendation:
v18.0 , 2018.07.22
v18.1 , 2018.10.05
v19.0 , 2019.01.22
v19.0.1 , 2019.01.23

Alternative Solutions
You can use Major Minor Point, or Dates like 2018-07-22.
But Mixing?

Additional context
https://xkcd.com/1179/

[RonnyPfannschmidt]

https://calver.org/ is a established standard

[dlamblin]

I get that it's not unheard of… but wouldn't a 4 digit year at least make it unmistakably obvious what you chose and mean?

This "established standard" is not much more than a loose review of what has been tried regarding dates in version numbers by approximately one person.
I don't see it making any strong argument in favor of the format pip chose: a format that looks like a semantic version but is rather a two digit year and minor and micro number. It would seem to couple the potential confusion that the personal blog argues arises from semantic versioning with … dates.
So, it wouldn't be unusual for a user looking at 18.1 going to 19.0 to think "there must be a major change here" as opposed to what seems to be the intent of a date based version: it is more to say "this is newer than that, and approximately this recent".

It argues in favor for what I gather are these reasons:

• Easily calculating support time frames [at least it's not Best Before versioning]
• Coordinating many sub projects in simultaneous releases. [Okay, but anything could be applied uniformly, I don't see the date being an important factor]
• If your updates are about things that were finalized on or done with dates. [seems like a good plan]
• Then there's the argument of Teradata's brilliant combination of date and semantic versioning: when you use a date that is not related to the date of the release. [You lost me, we were making a case for what?]

There might be some upstream project that you're matching the versions to… and that could be an argument in favor, because the decision is out of your hands.

[xavfernandez]

Both format would be fine but the YY format has been chosen in #5324 and is unlikely to change.

[dlamblin]

It will change. Maybe not this year, or five years from now, but someone will end up looking for some open-source points and make a more strongly worded argument than mine… mine is just: your version is not a date. You can't pretend it is one. It does not tell users that you are or are not committed to breaking changes and a cadence.

[xavfernandez]

That ship has sailed.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.