issue_comments

Table actions

6 rows where author_association = "MEMBER" and issue = 1108564253 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

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

issue 1

  • Xarray versioning to switch to CalVer · 6 ✖

author_association 1

  • MEMBER · 6 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
1057657161 https://github.com/pydata/xarray/issues/6176#issuecomment-1057657161 https://api.github.com/repos/pydata/xarray/issues/6176 IC_kwDOAMm_X84_CpFJ shoyer 1217238 2022-03-03T04:32:10Z 2022-03-03T04:32:10Z MEMBER

Breaking changes will continue to be very rare, and whenever possible will be preceeded by deprecation or future warnings for multiple months.

 
{
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Xarray versioning to switch to CalVer 1108564253
1025382413 https://github.com/pydata/xarray/issues/6176#issuecomment-1025382413 https://api.github.com/repos/pydata/xarray/issues/6176 IC_kwDOAMm_X849HhgN jhamman 2443309 2022-01-31T05:02:19Z 2022-01-31T05:02:19Z MEMBER

After thinking on this one a bit, I'm back to thinking we should zero-pad the months. I don't think there is a clear right choice here, with both options offering pros/cons. Thanks @ksunden in particular for sharing your perspective). I suggest we try this in 2022.02.0. See #6214 for more details.

 
{
    "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
1020614631 https://github.com/pydata/xarray/issues/6176#issuecomment-1020614631 https://api.github.com/repos/pydata/xarray/issues/6176 IC_kwDOAMm_X8481Vfn keewis 14808389 2022-01-24T22:28:27Z 2022-01-24T22:46:02Z MEMBER

note that PEP440 itself is not really consistent: it mentions both normal and zero-padded CalVer.

Also, in the issue in which dask discussed this, one of the people involved with the PyPA stated that the difference between omitting or keeping the zero-padding is purely aesthetic (both can be parsed using packaging.version.Version / packaging.version.parse). I assume that means we're free to choose? The YYYY.MM.X scheme seems to be fairly common now, though.

Edit: I would vote for zero-padding of the months because that will make it actually recognizable as a date.

 
{
    "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
1020525378 https://github.com/pydata/xarray/issues/6176#issuecomment-1020525378 https://api.github.com/repos/pydata/xarray/issues/6176 IC_kwDOAMm_X8480_tC Illviljan 14371165 2022-01-24T20:37:32Z 2022-01-24T20:37:32Z MEMBER

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.

No opinion either way here but 2022.01.0 is an easier string to sort.

@jrbourbeau is this something dask has thought about?

 
{
    "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
1020519502 https://github.com/pydata/xarray/issues/6176#issuecomment-1020519502 https://api.github.com/repos/pydata/xarray/issues/6176 IC_kwDOAMm_X8480-RO andersy005 13301940 2022-01-24T20:30:05Z 2022-01-24T20:30:05Z MEMBER

Do others have thoughts here? I would support stripping the leading zeros from the MM part of the version string in favor of consistency here.

I'm in favor of a non-zero-padded version for the benefit of having canonical/normalized versions that also match git tags/history

 
{
    "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
1020463316 https://github.com/pydata/xarray/issues/6176#issuecomment-1020463316 https://api.github.com/repos/pydata/xarray/issues/6176 IC_kwDOAMm_X8480wjU jhamman 2443309 2022-01-24T19:27:38Z 2022-01-24T19:27:38Z MEMBER

Interesting insights @ksunden, thanks for sharing!

Do others have thoughts here? I would support stripping the leading zeros from the MM part of the version string in favor of consistency here. 

{
    "total_count": 1,
    "+1": 1,
    "-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]);