Release v0.19?

[TomNicholas]

Yesterday in the dev call we discussed the need for another release. Not sure if this should be a bugfix release (i.e. v0.18.3) or a full release (i.e. v0.19). Last release (v0.18.2) was 19th May, with v0.18.0 on 6th May.

@pydata/xarray

Bug fixes:

• Error slicing CFTimeIndex with Pandas 1.3 #5581 and the fix Make kind argument in CFTimeIndex._maybe_cast_slice_bound optional #5359 (this one needs to be released soon really)
• Undeprecate dict argument for coords in DataArray (#5527) #5528
• Probably various smaller ones

New features:

• combine_by_coordinates to handle unnamed data arrays. #4696
• Allow user to explicitly disable coordinates attribute #5514
• Add coarsen.construct #5476
• Allow plotting categorical data #5464
• Add xr.unify_chunks() top level method #5445

Internal:

• master -> main update references to master #5520
• Refactor dataset groupby tests #5506

Nice to merge first?:

• Add to_numpy() and as_numpy() methods #5568 and Plots get labels from pint arrays #5561
• Rely on NEP-18 to dispatch to dask in duck_array_ops #5571
• Accept missing_dims in Variable.transpose and Dataset.transpose #5586
• Fix bug when querying unnamed dataarray #5493
• Add dataarray scatter with 3d support #4909
• dataset __repr__ updates #5580
• apply to dataset #4863
• fix dtype complex for rasterio backend #5501

[keewis]

is there a way to tag only the core dev team?

as long as you're a member you can use @pydata/xarray

[dcherian]

There's a breaking change so it should be 0.19.0: https://xarray.pydata.org/en/latest/whats-new.html

[keewis]

we were also wondering whether a renamed kwarg went through a deprecation cycle, but I can't find that PR. Has it been merged, yet?

[dcherian]

@keewis See #4696 . that whats-new note is in the wrong place which is why I couldn't find it yesterday

[keewis]

there are also a few deprecations scheduled for removal in 0.19

[TomNicholas]

I know I volunteered to do this release, but some of the PRs I wanted to include have taken longer than I thought they would (particularly #5571), and now I'm going to be away from a computer from tomorrow until near the end of next week.

Should we do the release soon anyway?

[dcherian]

Should we do the release soon anyway?

Yes!

[max-sixty]

I basically think we should never wait for PRs, or spend time "rounding them up" before doing a release. Stuff is going to go in at some point, and exactly when doesn't matter as much as reducing the burden of doing releases. Indeed — even if we're only attempting to reduce the time between code merging and being released — we'd arguably reduce that more by forgoing this rounding up effort, making releases easier and more frequent.

The only argument I can see is that it's some "call to action" that helps motivate people to push something over the edge.

(but not super confident and realize I am maybe contra-consensus, so weigh appropriately)

[TomNicholas]

@max-sixty I think it somewhat depends on the intended purpose of the release: new features or bug fixes? Here the primary motivation was a bug fix so I agree with you in this case.

…

On Fri, 16 Jul 2021, 12:31 Maximilian Roos, ***@***.***> wrote: I basically think we should never wait for PRs, or spend time "rounding them up" before doing a release. Stuff is going to go in at some point, and exactly when doesn't matter as much as reducing the burden of doing releases. Indeed — even if we're only attempting to reduce the time between code merging and being released — we'd arguably reduce that more by forgoing this rounding up effort, making releases easier and more frequent. The only argument I can see is that it's some "call to action" that helps motivate people to push something over the edge. (but not super confident and realize I am maybe contra-consensus, so weigh appropriately) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#5588 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AISNPI6RT2U2VKR5KPSTYLTTYB3JXANCNFSM5ABEGYEQ> .

[shoyer]

I'd like to consider rolling back the addition of typing-extensions as a required dependency before issuing the release: #5495

[TomNicholas]

Is this just blocking on #5495? What did we decide to do there?

[tlvu]

Is it possible to make quick release of xarray? Without a release containing PR #5359, we are forced to pin pandas below 1.3.0. Thanks !

[dcherian]

Just merged the blocker. @TomNicholas we should be good to release.