PEP 602: Annual Release Cycle for Python

But we can not know about which Fedora version will be base of next RHEL…

I agree that Fedora is important distribution too. But since Fedora is about 6 months cycle, I don’t think we should schedule Python release based on it. It is same to Ubuntu non-LTS.

1 Like

Correct. I just wanted to point out that the release cycle of RHEL is not important here.

I don’t think Fedora users care all that much about having the latest CPython powering their systems. (And developers, venv users, are fine – they can use new and old CPythons packaged without system integration.)

But, as part of releasing Fedora, all the packages are re-built with the new CPython version. This tends to uncover lots of issues both in CPython and projects that use it. We had 500+ bug reports for 3.8 – very many were not CPython issues, but we did get good overview of how AST changes, buildsystem changes, API removals, kw-only args, vectorcall, XML ordering, etc. affect the ecosystem.

Release alignment affects when we can do this (alpha/beta/rc), and how long we have to help finding and fixing the issues.

It’s certainly possible to do the testing in other places, or by other people. I don’t want Fedora to dictate CPython’s release cycle. On the other hand, there are benefits of aligning with a project focused on integration – hopefully enough to keep this in mind as one of the factors.

7 Likes

A small feedback from a user. I personally prefer long release cycle, so I would side with Steve Downer on two year cycle.

It is easier to communicate feature-wise on a big release and to motivate people to upgrade, because it creates a Momentum. More frequent releases create less momentum because of the repetition. That’s clearly a subjective opinion of course but I do stand by it.

Another feedback I would like to give is that in my company, people do not really have smooth upgrade path. When they started using Python, they settled on Python 3.1 . Part of the company has now upgraded to Python 3.5 but the rest is still stuck on 3.1 . I am trying to initiate a move to 3.7 but it will take probably one year to have it executed. This means two things :

  1. My company does not plan release by relase upgrades. They jump from an antiquated version to whatever is the current one, usually with a kick in the butt (“What, windows XP is not maintained anymore ?”). So all the plan about feature deprecation for two releases, extra warnings and stuff does not really work. When they did the 3.5 transition, nobody checked what happened with 3.2, 3.3 and 3.4 . With a one year release cycle, the jump will be even bigger and I am concerned by this.

  2. It takes more than one year to complete an internal migration. It is frustrating to work one’s ass to organise a big migration and having people come to you asking why we moved to an obsolete version since a new one is out (grrrr).

1 Like

These two points seem to be contradictory. So is the former a personal feeling while the latter is how things are for you at work?

Assume everything will shift accordingly such that deprecations last about as long as they do now time-wise (this is not guaranteed, but I’m willing to bet this is how we will solidify our deprecation process). I.e. if we move to an annual release cadence we could quite possibly set a policy of deprecations must last 18 months in a final release which would mean two releases at an annual release cadence or one release under two years.

They are not as contradictory as you could think. Because bigger feature create a bigger momentum, it is much easier to advocate for them in my work environment. For example, I plan to use the progresses in type-annotations as a motivator to switch to something newer than 3.5 .

Less releases also simplifies the landscape of which version we should target.

This is akin to what used to happen for me at Boeing (in the 2.2 -> 2.6 era), with two major things dictating the Python versions used:

  • new projects usually started out with whichever version of CPython was current at the time. This also included scheduled refreshes of existing systems (which were usually planned on a 3-5 year timetable in order to meet 10-15 year overall system lifetime requirements)
  • it usually took two releases worth of feature additions (i.e. ~3 years) for an older version of CPython to become obviously worse than the latest release, such that nobody actually tried to argue in favour of sticking with the old version beyond that point

It’s not a model I’d recommend if continuous incremental upgrades are an available alternative, but it’s also a model that’s likely to remain pretty common (especially in industries with strict certification requirements).

This alternative proposal has now been published as PEP 605, and has a separate discussion thread at PEP 605: A rolling feature release stream for CPython

Request for final comments

As discussion on this particular proposal died out and I’m happy with its current form, I’d like to file a motion for final comments on this PEP. Given no additional issues are identified, I’d like to put the PEP under the Steering Council’s consideration on October 17th (two weeks from now).

The Steering Council will likely want to wait with deciding on the PEP until the alternative PEP 605 takes final form and is sufficiently discussed. That’s expected, I don’t mean to rush things. However, release cadence PEPs are special in the sense that they are literally tied to the calendar. I would like to signal that the proposal described in PEP 602 is ready.

One consequence of this is that on Monday, October 14th I will be releasing the first alpha of Python 3.9.0 as described in the PEP above. I thought about this for a while and I hope you won’t be seeing this as forcing anybody’s hand. In fact, should PEP 602 be ultimately rejected, this is a harmless event, we will just have one additional alpha tagged unusually early. However, should PEP 602 be accepted in the future, the calendar described in the PEP will be upheld.

3 Likes

We actually discussed this at the last steering council meeting and we decided to let PEP 602 and PEP 605 try and finish their discussions naturally before we exerted any time pressure to try and resolve this before 3.9 scheduling would be impacted and before the election starts since that will basically freeze up PEP decision making until mid-December.

2 Likes

I hadn’t raised it before, as I thought you were already planning to address it, but the questions in https://www.python.org/dev/peps/pep-0602/#some-policies-depend-on-the-release-cadence need concrete proposed answers in the PEP itself.

It would be fine to make that a simple adjustment that assumes a non-trivial proportion of users will only be running every other release:

  • Deprecation cycles: 2 releases (up from 1)
  • __future__ imports: 2 releases (up from 1)
  • Release manager term: keep at 2 releases (~7 year commitment vs current ~8)
  • Steering Council: 2 releases (up from 1, pending a core dev vote for a PEP 13 update)

That way, these aspects would be essentially the same between PEP 602 and PEP 605, and the core process decision to be made would be between:

  • 3.9.0 in late 2020 (support cycle through to late 2025) + 3.10.0 in late 2021 (support cycle through to late 2026); and
  • rolling releases from late 2019 through to mid 2021 (each only supported until the next one comes out) + 3.9.0 in late 2021 (supported through to late 2026)
2 Likes

source-only releases never fit the brain (nor the need) for Windows users. Any maintenance release shall have installable binaries (and continous integration environements)