Dask versioning to switch to CalVer

[mrocklin]

Dask is planning to switch to Calendar versioning (calver)

This has been discussed in several issues (like #93 ) and was met with fairly unanimous consent in the last community meeting. If there are major objections we're still happy to hear them, but at this point I think that the default choice is to move to CalVer rather than wait-and-see.

This issue is here to serve as a general announcement, and for logistics about the move. I would expect this change to happen within the next month.

[mrocklin]

I suggest that we use the versioning scheme YY.MM.DD, so if we were to release today it would be version

>>> dask.__version__
"20.10.06"

[jakirkham]

What about doing YYYY.MM.DD? This is typically what I see projects using CalVer do. For example certifi

[djhoese]

What about a patch release in the same day?

[jcrist]

Whatever we choose we'll want to make sure it's pep440 compatible. Rules here: https://www.python.org/dev/peps/pep-0440/#public-version-identifiers

[jrbourbeau]

Yeah, following up on @djhoese point, it doesn't happen often, but we might publish a release, discover a critical bug and want to publish a fixed release the same day. What about YY.MM.XX where XX is a zero-padded increment for the releases that month? This seems similar to what Ubuntu and Twisted do

[jcrist]

What about YY.MM.XX where XX is a zero-padded increment for the releases that month?

That sounds good to me, but makes it a bit harder to automate the versioning (we'd have to check some central registry to see what the last release was or something). Using a date is much simpler, since the version is based on the date alone. Speaking of this, we'd need to transition from versioneer to some other solution, preferably one that prevents duplicating version info between setup.py and __init__.py.

[gforsyth]

potential small issue (that we can figure a way around), I don't think you can have a zero-pad between . since pep440 uses int() to parse some stuff.

Could do YYYYMMXX / YYMMXX (which is admittedly a bit harder to read)

[jcrist]

Seems to work fine for me:

In [3]: from distutils.version import StrictVersion

In [4]: StrictVersion("20.01.01")
Out[4]: StrictVersion ('20.1.1')

We also don't need to zero pad at all, since the . delimiter already handles splitting between year/month/point release.

[gforsyth]

In [4]: StrictVersion("20.01.01")
Out[4]: StrictVersion ('20.1.1')

Sorry, I wasn't clear. I meant the zero-pad won't survive pep440, which is probably not a huge deal.

[martindurant]

If it doesn't cause a problem, I would prefer zero-padding, so that string sort and number sort do the same thing.

[mrocklin]

What about doing YYYY.MM.DD? This is typically what I see projects using CalVer do. For example certifi

Some examples of YY.MM.DD include Ubuntu and pip. I think it comes down to whether we want users to identify our version as a date, or hide the calendar nature of the versioning.

[mrocklin]

What about a patch release in the same day?

We can always bend time and travel to the future by a day if we need to.

[jcrist]

If it doesn't cause a problem, I would prefer zero-padding, so that string sort and number sort do the same thing.

That's what using StrictVersion/LooseVersion is for. Even our existing versioning scheme doesn't allow for string sorting of versions. I'd prefer to not zero-pad if possible, as the zeros don't add anything meaningful, and don't follow pep440.

[martindurant]

I'd prefer to not zero-pad if possible, as the zeros don't add anything meaningful, and don't follow pep440.

I don't insist, and that's good enough reason not to... but you do occasionally end up dealing with git tag strings or pip installable blob files

[pradyunsg]

puts on "I know waaaay too much about the Python packaging standards" hat

20.01.01 / 2020.01.01 are valid PEP 440 versions.

>>> from packaging.version import Version
>>> v = Version("2020.01.01")

The fact that it does not error out here means that it's a valid PEP 440 version. The only thing that you may want to worry about here is that the "canonical" form of that version isn't the same as the version itself:

>>> from packaging.utils import canonicalize_version
>>> str(v)
'2020.1.1'
>>> canonicalize_version("2020.01.01")
'2020.1.1'

However, note that things will still work even if there's zero-padding:

>>> Version("2020.01.01") == Version("2020.1.1")
True

Overall, the choice between 0Y/0M/0D vs YY/MM/DD is purely a aesthetic one -- either will work with basically every Python Packaging tool that follows the standards.

---

Oh, and... https://pypi.org/project/calver/ is a thing you might want to use, in case you're using setuptools. :)

---

PS: Please don't use distutils for... well... anything. pip, PyPI and most of the other Python packaging uses packaging.version for handling versions -- it's the reference/main implementation of PEP 440 and friends. At the cost of using a slightly grim analogy, distutils is brain-dead and we're gonna turn off the life support soon.