RLS: 1.4

[simonjayhawkins]

Tracking issue for the 1.4 release. (it's possible we make this 2.0 at some point - not determined yet)

https://github.com/pandas-dev/pandas/milestone/86

Currently scheduled for December 31, 2021 (with a release candidate around 2 weeks before)

List of open regressions: https://github.com/pandas-dev/pandas/issues?q=is%3Aopen+is%3Aissue+label%3ARegression

[simonjayhawkins]

@pandas-dev/pandas-core @pandas-dev/pandas-triage

[rhshadrach]

Is this a good place to discuss whether it should be 1.4/2.0? Or should a new issue be opened?

[simonjayhawkins]

here is fine imo. but not knowing how big a discussion it would be, opening a new issue is also fine by me.

[rhshadrach]

I'm +1 on 2.0 Changed - see below

[jbrockmendel]

whether it should be 1.4/2.0?

Has there been a discussion about unannounced API changes (e.g. deprecations that didn't make it into 1.3)? I'm thinking of #41943 and some MultiIndex behavior that I would want to deprecate if we're doing a 1.4.

[jorisvandenbossche]

some MultiIndex behavior that I would want to deprecate if we're doing a 1.4.

I think it is OK to do such deprecation if you want to look at that now, regardless of the final decision on 1.4 vs 2.0 (if it ends up becoming 2.0, the deprecation would then stay the full 2.x cycle I guess, like deprecations done in later 2.1 etc releases)

[rhshadrach]

Agree with @jorisvandenbossche - while we can make breaking changes in 2.0, I'd prefer having a deprecation first (at least in general - perhaps a special case may be warranted). By deprecating, we allow user feedback before a removal/change takes place.

I'm changing my vote above, I'm +1 on 1.4 (but okay with 2.0 too). There are some apply deprecations I would like to get in so that things can start to be fixed in 2.0.

[jbrockmendel]

IIRC on last week's call we were leaning towards doing a 1.4

[lithomas1]

#42587 forces us to have a 1.4, since it changes the empty series deprecation warning from a DeprecationWarning to a FutureWarning. If we want to do 2.0, we'd have to revert that(not sure though if its ok to deprecate something with only a DeprecationWarning).

[auvipy]

#42587 forces us to have a 1.4, since it changes the empty series deprecation warning from a DeprecationWarning to a FutureWarning. If we want to do 2.0, we'd have to revert that(not sure though if its ok to deprecate something with only a DeprecationWarning).

going with 1.4 would be a sane idea

[attack68]

I was hoping to raise a FutureWarning for the DataFrame.to_latex and DataFrame.to_html (and possibly DataFrame.to_string) methods to utilise the Styler implementation and to do away with the HTMLFormatter and LateX Formatter classes. That would be for 2.0, though, and currently those warnings would have to be in 1.4

[h-vetinari]

Regarding breaking changes, is there any appetite whatsoever to fix the return type of Series.unique, cf. #24108? I didn't manage to get all things into place before 1.0.

[jreback]

@h-vetinari yes that would be a change that would be good to make on a breaking release