Align with CPython release

[hugovk]

CPython is moving from an 18-month to an annual release cycle, with releases in October (PEP 602). CPython 3.9.0 is currently scheduled for 2020-10-05 (PEP 596).

To prevent double work of us making a 2020-10-01 release (eg. 7.2.0), and then a patch version (eg. 7.2.1) a few days later with new wheels, I'd like to suggest we make the October release when the new CPython is ready for us to support it.

---

As an example, let's look at the last CPython 3.8.0 release:

• 2019-10-01 Pillow 6.2.0 released (Release Pillow 6.2.0 on October 1, 2019 #3968)
• 2019-10-14 Scheduled and actual release of CPython 3.8.0 (PEP 569)
• 2019-10-21 Dependencies in place and we released Pillow 6.2.1 (Support Python 3.8 #4110, Release Pillow 6.2.1 on October 21, 2019 #4152)

Assuming no CPython slippage, and 7 days for our dependencies to be updated:

• 2020-10-05 CPython 3.9.0 scheduled release
• 2020-10-12 Pillow release?

Of course, CPython 3.9.0 could slip, and our dependencies might be ready sooner, or later, so we won't know for sure until things are ready.

---

Would some time later in October be acceptable? Or is it too long?

We could pick a cut-off date (eg. middle or last day of October), and if Py3.9 things aren't ready, we release a non-Py3.9 one, and make a second when with Py3.9 when we can.

Thoughts?

Ping @python-pillow/pillow-team and anyone else interested!

[aclark4life]

@hugovk I would ignore their release schedule and just stick to ours, unless there is some compelling reason to do otherwise … which I'm not seeing here. Not saying there is no compelling reason, just that if there is, I'm not sure what it is. (The fact that the releases are close to each other on the calendar is not particularly compelling to me, why do we care? I don't recall us ever doing a point release after some new Python came out. Rather, we target supporting that release after it's been released… correct me if I'm wrong.)

[hugovk]

I don't recall us ever doing a point release after some new Python came out. Rather, we target supporting that release after it's been released… correct me if I'm wrong.

It's a new thing, but we do:

• We did the Pillow 6.2.1 point release a week after Python 3.8 came out, solely to support 3.8. (With three weeks between 6.2.0 and 6.2.1.)

• Python 3.7 was released on 2018-06-27, which aligned perfectly to go into the regular 2018-07-01 Pillow release (Release Pillow 5.2.0 on July 1, 2018 #3154).

• Python 3.6 was released on 2016-12-23, also aligned perfectly for the regular 2017-01-01 release (Release Pillow 4.0.0 on Jan 1, 2017 #2244).

People are keen to get the wheels for the new Python is out, if not before (eg. #2318, #2842, #3074).

It's generally not much work to actually add support (version bumps, docs, testing eg. 6.2.0...6.2.1, python-pillow/pillow-wheels#127), it's about the time to do the release itself.

[aclark4life]

@hugovk That's cool, I mostly don't care, except I love the quarterly release schedule and I think it has served us well (as far as I can tell).

That said, if we permanently change Jan 1 to Jan 2 (to avoid work on holiday) and Oct 1 to Oct 15 (to coordinate with CPython) that's probably OK with me.

[hugovk]

Sounds good.

I agree, the quarterly release schedule has been and remains very good, it keeps a good cadence for the project, and I think a few days shifted is fine.

So if the CPython release + dependencies aren't ready by October 15th, do we release as usual and later make a point release when they are ready?

[aclark4life]

@hugovk Probably, I definitely wouldn't want to wait around for it. Adjusting schedule to align is one thing, but dependency on their release is probably not our game.