issue_comments

Table actions

4 rows where author_association = "CONTRIBUTOR" and issue = 1108564253 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: created_at (date), updated_at (date)

user 3

issue 1

  • Xarray versioning to switch to CalVer · 4 ✖

author_association 1

  • CONTRIBUTOR · 4 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
1057653294 https://github.com/pydata/xarray/issues/6176#issuecomment-1057653294 https://api.github.com/repos/pydata/xarray/issues/6176 IC_kwDOAMm_X84_CoIu brews 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
}
   Xarray versioning to switch to CalVer 1108564253
1020681788 https://github.com/pydata/xarray/issues/6176#issuecomment-1020681788 https://api.github.com/repos/pydata/xarray/issues/6176 IC_kwDOAMm_X8481l48 jrbourbeau 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
}
   Xarray versioning to switch to CalVer 1108564253
1020669305 https://github.com/pydata/xarray/issues/6176#issuecomment-1020669305 https://api.github.com/repos/pydata/xarray/issues/6176 IC_kwDOAMm_X8481i15 ksunden 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
}
   Xarray versioning to switch to CalVer 1108564253
1020405910 https://github.com/pydata/xarray/issues/6176#issuecomment-1020405910 https://api.github.com/repos/pydata/xarray/issues/6176 IC_kwDOAMm_X8480iiW ksunden 2501846 2022-01-24T18:23:26Z 2022-01-24T18:23:26Z CONTRIBUTOR

Note that PEP 440 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
}
   Xarray versioning to switch to CalVer 1108564253

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options: 

CREATE TABLE [issue_comments] (
   [html_url] TEXT,
   [issue_url] TEXT,
   [id] INTEGER PRIMARY KEY,
   [node_id] TEXT,
   [user] INTEGER REFERENCES [users]([id]),
   [created_at] TEXT,
   [updated_at] TEXT,
   [author_association] TEXT,
   [body] TEXT,
   [reactions] TEXT,
   [performed_via_github_app] TEXT,
   [issue] INTEGER REFERENCES [issues]([id])
);
CREATE INDEX [idx_issue_comments_issue]
    ON [issue_comments] ([issue]);
CREATE INDEX [idx_issue_comments_user]
    ON [issue_comments] ([user]);