RLS: 1.2

[simonjayhawkins]

Tracking issue for the 1.2 release. https://github.com/pandas-dev/pandas/milestone/73

Planning a release candidate for sometime towards the end of the month, 1-2 weeks before the final release.

List of open regressions: https://github.com/pandas-dev/pandas/issues?q=is%3Aopen+is%3Aissue+label%3ARegression (includes regressions that may be included in 1.1.5)

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

[simonjayhawkins]

nightly builds on master are currently failing. https://dev.azure.com/pandas-dev/pandas-wheels/_build/results?buildId=48433&view=results

the failures for 3.7 (for linux and macOS) are related to -Werror. (not applicable to Windows)

 #warning "Using deprecated NumPy API, disable it by " \
  ^
cc1: all warnings being treated as errors

These are not failing on 1.1.x. In setup.py on 1.1.x we have

# in numpy>=1.16.0, silence build warnings about deprecated API usage
#  we can't do anything about these warnings because they stem from
#  cython+numpy version mismatches.
macros.append(("NPY_NO_DEPRECATED_API", "0"))
if "-Werror" in extra_compile_args:
    try:
        import numpy as np
    except ImportError:
        pass
    else:
        if np.__version__ < LooseVersion("1.16.0"):
            extra_compile_args.remove("-Werror")

this has been removed on master in since the min numpy version for pandas 1.2 is now 1.16.5

in MacPython we have NP_BUILD_DEP: "1.14.5" for 3.7

we need to get the nightly builds to pass (and before 1.2rc0 release) while also allowing 1.1.5 to build.

in MacPython/pandas-wheels#111 I have changed to NP_BUILD_DEP: "1.16.5" for 3.7 and indeed the py37 wheels are building.

in MacPython/pandas-wheels#109 I have done the same to check that this change will not affect the 1.1.5 release

Will be opening a PR shortly on MacPython with this change. (if MacPython/pandas-wheels#109 passes)

[simonjayhawkins]

the pip-test and conda-test stages of the release process are currently failing. https://github.com/simonjayhawkins/pandas-release/runs/1447063807?check_suite_focus=true

have reproduced this locally, so will investigate further.

[simonjayhawkins]

the pip-test and conda-test stages of the release process are currently failing. https://github.com/simonjayhawkins/pandas-release/runs/1447063807?check_suite_focus=true

#35895 added the use of the worker_id fixture, which is only available if pytest-xdist is installed. see #35895 (comment)

IIUC pytest-xdist is an optional dependency and pd.test is part of the public api https://pandas.pydata.org/docs/reference/api/pandas.test.html

cc @TomAugspurger

[jreback]

@pandas-dev/pandas-core don't tag any more issues /PRs for 1.2, unless they are actually ready to merge, better to just ping and say ready for 1.2

[simonjayhawkins]

wrt documentation

• there's a significant clean-up in DOC: Whatsnew 1.2.0 cleanup #38002 to be merged before another pass.
• imo the tracebacks are a distraction https://pandas.pydata.org/pandas-docs/dev/whatsnew/v1.2.0.html#optionally-disallow-duplicate-labels - any alternative to this?
• need to add contributors
• if 1.2.0rc0 is released before 1.1.5 we may want to start the 1.2.x branch before tagging 1.2.0rc0 and remove the 1.1.5 release notes first
• have done dummy release locally for 1.2 and built the docs. issue DOC: corrupted function signatures on stable #37813 is not an release environment issue, function signatures are fine.

[jorisvandenbossche]

imo the tracebacks are a distraction https://pandas.pydata.org/pandas-docs/dev/whatsnew/v1.2.0.html#optionally-disallow-duplicate-labels - any alternative to this?

Yes, I also noticed that and wanted to do something about it. I think the easiest alternative for now is a plain code-block with the output we want (nicer general solution would be #10715)

[simonjayhawkins]

1.1.5 is in a good state for release. Not sure whether the preference is to do 1.1.5 before/after 1.2.0rc0

I'll open an issue for tracking the 1.1.5 release shortly. I'm thinking, looking at the open issues, that will just remove milestones from all the open issues, with a message about a imminent release and stating community contributions welcome.

Some of the issues have now had the milestone changed several times, some from 1.0.x. So that's why I think we could now just remove the milestone altogether. If I do this today, that will give interested parties time to comment prior to the release.

Scheduled for Monday. but could do say 1.2.0rc0 Monday, 1.1.5 following Monday, and 1.2 the Monday after that.

thoughts?

[simonjayhawkins]

Yes, I also noticed that and wanted to do something about it.

I think, unlike code changes, it's ok to tidy release notes between 1.2.0rc0 and 1.2, so not a blocker imo.

I'm going to look at the tag script later, so that the v1.2.0rc0 tag, the 1.2.x branch and v1.3.0.dev0 tags are created atomically, to try an deter any changes after tagging the release candidate other than reported bugs/regressions (with the rc). Any older bugs/regressions could perhaps wait for v1.2.1

[jorisvandenbossche]

I don't know if an rc for 1.2 on Monday is realistic, given the number of open issues?

Regarding the issues tagged for 1.1.5: I agree that several of them can be removed from that milestone (eg some performance regressions of a year old that were already partly solved). But the actual behaviour regressions, if not removing from the 1.1.5 milestone should then be added to the 1.2 (or 1.2.1) milestone, IMO, so we don't loose track of them.

[jorisvandenbossche]

BTW, I have find it easier in the past to create a temporary milestone for "1.2.0rc", so we can distinguish between issues that only need to be fixed before the final 1.2 release, and issues that are blockers for the RC. After the RC we can put the issues labeled with 1.2.0rc back to the 1.2 milestone with a batch change, and remove the milestone.
(just a suggestion, up to you)

[simonjayhawkins]

BTW, I have find it easier in the past to create a temporary milestone for "1.2.0rc", so we can distinguish between issues that only need to be fixed before the final 1.2 release, and issues that are blockers for the RC. After the RC we can put the issues labeled with 1.2.0rc back to the 1.2 milestone with a batch change, and remove the milestone.
(just a suggestion, up to you)

That sort of goes against my thinking that a release candidate is moreless final subject to any issues with the rc.

I'm not keen on doing a rc if there are more changes planned before the final release.

[simonjayhawkins]

But the actual behaviour regressions, if not removing from the 1.1.5 milestone should then be added to the 1.2 (or 1.2.1) milestone, IMO, so we don't loose track of them.

on a similar vein to my above response. I wouldn't be keen on moving them to 1.2, ok with 1.2.1 though.