RLS: 1.1.5

[simonjayhawkins]

Tracking issue for the 1.1.5 release.

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

[simonjayhawkins]

Currently scheduled for November 30, 2020, date may change depending on discussions about 1.2.0rc0 release. see #37784

[simonjayhawkins]

There are currently no blockers here and wheels are building so could release anytime.

There are a number of open issues that are currently milestoned 1.1.5 that intereted parties should be aware that have not been addressed and therefore the release should imo not be before November 30, 2020 to give people a chance to comment.

see #37784 (comment)

[simonjayhawkins]

@jorisvandenbossche following discussion in #37784 (comment)

proposed comment for the open issues...

This issue is milestoned 1.1.5. This issue has not yet been addressed and the 1.1.5 release is scheduled for Monday, November 30, 2020. The 1.2 release candidate is also imminent. The milestone is therefore being moved to 1.2.1. Contributions from the community are always welcome and PRs opened before the release of 1.1.5 may still be reviewed and merged in time to be included in v1.1.5.

[simonjayhawkins]

During the 1.1.x releases, I requested others (and did myself) to tag issues that were regressions from 1.0.5 with the next 1.1.x milestone.

Now that we approach the end of the 1.1.x series of releases, I'd be interested on other's views on this process and whether to do the same for 1.2.x.

I think that it provided better tracking/visibility for those issues. The downside is that without allocating the issues to individuals some issues were moved from milestone to milestone.

As @jorisvandenbossche mentioned in #37784 (comment)

we do potentially have some support for maintenance, and fixing release blockers can be part of that.

maybe we can extend that to regressions in general (and track using the regression label and not the milestone label)

Moving from milestone to milestone may be seen as unprofessional, so I propose that we don't add the milestones to the issues for future reported regressions unless we have someone allocated to fix.

@pandas-dev/pandas-core

[jreback]

Moving from milestone to milestone may be seen as unprofessional, so I propose that we don't add the milestones to the issues for future reported regressions unless we have someone allocated to fix

it is impossible to fix everything w/o dedicated and paid resources

we do the best we can and it is what it is

we release pretty frequently and we do a good job

the worst thing we could do is delay releases to make sure 'everything is fixed' that would mean we essentially never release

regressions on a project this size can and do happen

[jreback]

@simonjayhawkins I think go for release here (if you want to merge the cython PR go for it, ok not to as well)

[simonjayhawkins]

see #37784 (comment) and #37784 (comment)

Unless our goal is to actually fix them. IMO we should take the time to go through the remaining issues, identify the important regressions, and actually try to fix them before the release. Even if that delays the release a little bit, IMO that's still a good outcome. We have some support for maintenance now, and fixing release blockers can be part of that IMO.

so continuing to push ahead with the 1.2.0rc0 release as scheduled (and then backporting any regression fixes on master for 1.2.0) and re-scheduling the 1.1.5 release for December 07, 2020 was intended to strike a balance/find some middle ground here.

[jreback]

@simonjayhawkins i would simply release now

[simonjayhawkins]

OK. i'll do this before 1.2.0rc0 for simplicity if they are both being released around the same time.

wheels for Windows 3.6 aren't building (maybe others, test not yet complete) MacPython/pandas-wheels#109

but won't block on these. will open PR to set the release date to today in the 1.1.5 release notes shortly if the others are green.

It's much later in the day here than when I normally start a release, so may not complete process today.

[simonjayhawkins]

wheels for Windows 3.6 aren't building

seems to be in the python setup.py build step, maybe #37732 related

[simonjayhawkins]

locally i'm getting a similar warning

C:\Users\simon\anaconda3\envs\py36\lib\site-packages\setuptools\dist.py:679: UserWarning: Module numpy was already imported from C:\Users\simon\anaconda3\envs\py36\lib\site-packages\numpy\__init__.py, but c:\users\simon\pandas\.eggs\numpy-1.19.4-py3.6-win-amd64.egg is being added to sys.path

but not picking up numpy-1.20.0rc1 so not failing to build with RuntimeError: Python version >= 3.7 required.

[simonjayhawkins]

looks like the issue is fixed by changing NP_BUILD_DEP to 1.15.4

[simonjayhawkins]

final pre-release checklist

• MacPython.pandas-wheels RLS v1.1.5 MacPython/pandas-wheels#109
• release readiness passing https://github.com/simonjayhawkins/pandas-release/actions?query=workflow%3A%22Tag+Release%22
• release notes checked https://pandas.pydata.org/pandas-docs/dev/whatsnew/v1.1.5.html
• ci checks https://github.com/pandas-dev/pandas/commits/1.1.x
• no open issues/PRs (except this one) https://github.com/pandas-dev/pandas/milestone/79