html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue
https://github.com/pydata/xarray/issues/6176#issuecomment-1057653294,https://api.github.com/repos/pydata/xarray/issues/6176,1057653294,IC_kwDOAMm_X84_CoIu,2049051,2022-03-03T04:24:14Z,2022-03-03T04:24:14Z,CONTRIBUTOR,"Using semver can be handy to signal breaking changes. Any thoughts on how xarray will handle breaking changes with calver? Any release can break, or during select periods, after a timeout, etc.?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1108564253
https://github.com/pydata/xarray/issues/6176#issuecomment-1020681788,https://api.github.com/repos/pydata/xarray/issues/6176,1020681788,IC_kwDOAMm_X8481l48,11656932,2022-01-25T00:19:49Z,2022-01-25T01:27:00Z,CONTRIBUTOR,"> @jrbourbeau is this something dask has thought about?

Thanks for the ping @Illviljan. Zero-padding dates did come up in the Dask calver discussion starting here https://github.com/dask/community/issues/100#issuecomment-704445214. In a nutshell, there was a slight preference towards using zero-padding (i.e. `2022.01.0` instead of `2022.1.0`) because the calendar nature of the version is more explicit and string sorting and full-fledged package sorting (like one would do with `packaging.version`) give the same result. 

As pointed out https://github.com/dask/community/issues/100#issuecomment-704468187 either convention is valid from a Python packaging perspective. FWIW I'm not aware of any issues that have come up from Dask using a zero-padded version number. The main thing that comes to mind is when checking out git tags for a specific release (e.g. `git checkout 2021.04.0` and `git checkout 2021.4.0` are not equivalent). That said, to my knowledge, this hasn't been an issue in practice. 

EDIT: To be clear, I'm not advocating for one convention over the other -- just providing context around Dask's decision","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1108564253
https://github.com/pydata/xarray/issues/6176#issuecomment-1020669305,https://api.github.com/repos/pydata/xarray/issues/6176,1020669305,IC_kwDOAMm_X8481i15,2501846,2022-01-24T23:57:13Z,2022-01-24T23:57:13Z,CONTRIBUTOR,"`setup.py sdist bdist_wheel` creates files in `dist/` that have the leading zeros removed.

I did `git tag v2022.01.0` and then built the wheel/sdist and got: `xarray-2022.1.0-py3-none-any.whl` and `xarray-2022.1.0.tar.gz` and `xarray.__version__` gave `2022.1.0`

I do understand the appeal of leading zeros, I started off using them myself, but pypi/setuptools/etc _will_ bring in inconsistencies that you will either need to fight against or give into the consistent way, which is sans leading zero (that is the path I chose)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1108564253
https://github.com/pydata/xarray/issues/6176#issuecomment-1020405910,https://api.github.com/repos/pydata/xarray/issues/6176,1020405910,IC_kwDOAMm_X8480iiW,2501846,2022-01-24T18:23:26Z,2022-01-24T18:23:26Z,CONTRIBUTOR,"Note that [PEP 440](https://www.python.org/dev/peps/pep-0440/#integer-normalization) normalizes integers in version strings, so leading zeros are ignored and the version as it appears in PyPI would be `2022.1.0`, as that displays the normalized version string.


On my own packages which I use calver for I have opted to not have leading zeros such that the ""canonical"" version matches the ""normalized"" version to avoid any confusion that may cause.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1108564253