Petition: abandon plans to ship a 2.7.18 in April

Like many others, I was watching pythonclock.org to celebrate the end-of-life for Python 2.7 at the end of 2019, when someone shared a link to the announcement Python 2 series to be retired by April 2020.

My understanding is that Python 2.7 is end of life, and 2.7.18 will simply “close up shop” by releasing the last outstanding changes on the 2.7 branch.

However, I’m taken aback by the timing and phrasing of announcement, and the timing of the release. Sure, that’s irrational. But over the last five years I’ve put in a huge amount of work to ensure that my organisation is ready for Python 2’s end of life. Shipping another Python 2 release months afterward undermines the goal I’ve worked towards and the deadline I set my organisation.

There are good rational reasons not to proceed with Python 2.7.18:

  1. The end of life of Python 2 is a crucial milestone and messaging has suddenly become very confused. I read comments from several people who to seemed to take this as a postponement or a reprieve. And that’s completely understandable when the title of the announcement is “PYTHON 2 SERIES TO BE RETIRED BY APRIL 2020”.
  2. We’ve promised maintainers an end to the support burden of Python 2. Now that Python 2 is end of life we should expend no more energy or thought on it, and we should not cost anyone any more effort. Let’s give everyone a break, please.
  3. It should not become a precedent that end-of-life Python versions get releases months after the communicated death date. “End of life” should have a clear meaning, for the benefit of everyone who relies on these dates.

If it’s not acceptable to simply throw away work on the 2.7 branch and say that 2.7.17 was actually the last release, how about freezing a 2.7.18rc now, for a final release ASAP?

Yes, it wasn’t perfectly phrased.

You have to realize the April release is at the request of the release manager and is expected to be no different than the code that exists in the 2.7 branch as of 2020-01-01. Basically it is easier on the people involved who have been carrying Python 2.7 forward for over a decade – RMs start their work the day the last feature release came out which for 2.6.0 is 2008-10-01, and for Benjamin that’s over a third of his lifetime – and adds some catharsis to basically click the buttons to do the final release at PyCon US with the dev team in the room. If some absolutely horrible release-blocker bug that will cause the world to collapse comes in it could get fixed before then, but for all intents and purposes the Python 2.7 is in a protracted RC period and EOL’ed. IOW you can’t even get a spelling mistake fixed at this point and so the implication for you and your company is the same: you are not getting any upstream support anymore for Python 2.7 whether released yesterday or in less than 4 months time.

I understand being upset if you’re worried this going to cause you issues at work, but please do realize your phrasing comes off as not considering our needs and desires as the people who kept Python 2.7 running for as long as we have. Had you simply asked “why is the final release not on 2020-01-01?” then it wouldn’t come off as quite so hostile.

I apologise if I sound hostile. I’m not upset; I just described my initial surprise and confusion. I don’t translate that into hostility towards any of the dev team.

your phrasing comes off as not considering our needs and desires as the people who kept Python 2.7 running for as long as we have

That’s an uncharitable take. I am very supportive of those needs and desires in general.

A confluence of events at PyCon in order to initiate the celebrations is very much justified, but it does not need to be a release. You can still all have the catharsis and the party at PyCon with whatever ceremony you wish. Close the branch, delete the Python 2 docs from python.org, give a eulogy, whatever.

That contrasts with the challenge this release sets me to explain to my bosses and staff at my firm what the roadmap is for Python interpreter support. I’ve been telling them about this milestone for 3 years and releasing again in April gives me the job of reacting and explaining that change.

Then multiply that by tens or hundreds of thousands of users who might read this announcement.

Edit: Brett pointed out that I seemed to say celebration and catharsis were unjustified; that’s not what I meant.

It’s pretty straightforward, IMO (although I appreciate that the message wasn’t communicated as clearly as we would have liked). As of 1st January, no new bug reports, fixes, or changes will be made to Python 2. Any changes that might have been made since 2.7.17 shipped haven’t yet been released, but as a final service to the community, python-dev will bundle those fixes (and only those fixes) and release a 2.7.18. We plan on doing that in April, because that’s convenient for the release managers, not because it implies anything about when support ends.

Your proposal that we don’t ship a 2.7.18 would mean that people who expected that a post-2.7.17 fix made while 2.7 was still supported would end up in a released version would be let down, and in effect would mean that 2.7 support had ceased at the release of 2.7.17.

As Brett pointed out, python-dev is entirely made up of volunteers, and we’re trying to do our best for the community. We can’t please everyone, and we shouldn’t have to apologise if we don’t manage to.

You could start by pointing out that they have only ever had support on a volunteer basis, and they should not feel entitled to anything. If they want guarantees, or a roadmap, or any other form of commitment to a particular level of support, I’m sure there are companies out there who will provide that for a fee - even for Python 2.7, and even now that the python-dev team are no longer offering unpaid support.

I understand your frustration - companies have difficulty reconciling their need for stable systems and guaranteed support against the compelling cost argument that open source software offers (no need to pay!) But that’s a discussion you need to have with your company (as you are doing) - not something that you can expect to influence what python-dev chooses to do (except in the broad sense that we’re trying to do our best for people in general).

So far, you are the only person who’s flagged this as an issue, or spoken up here. I’m sure others exist who are in the same position, but one person willing to speak up out of all of them doesn’t suggest it’s a major problem (compared to, say, not releasing a final 2.7 version with the fixes from after 2.7.17). Even if there were a significant number of people supporting you, is it really worth the additional confusion that would result from such a change?

I don’t quite follow this reasoning: The purpose of the milestone
to end was to get people to start migrating over to Python 3, not to
cut them off of Python 2.

A later release of a Python 2.7.18 does change that. If businesses
want to only use officially supported software, they should have
completed the migration by now or asked a vendor to give them a support
contract which provides extended Python 2.7 support.

The timing of the 2.7.18 is entirely up to release manager and other
core devs who may want to help with the release. It’s a service
to the community, nothing more or less. PyCon US 2020 seems like
a great occasion to celebrate the last release and also to give
the people who have supported Python 2.7 for such a long time proper
credit.

If you read into this some form of support extension that’s really
just a misinterpretation of the announcement, which Brett has already
clarified.

Cheers,

Can I make a modest suggestion? The sunsetting page could be updated to clarify the situation. In the first paragraph, it says,

… we will not improve it anymore after [January 1, 2020].

That seems inconsistent with a final release in April. I’m not suggesting to change the release plan. If as Paul says, “the message wasn’t communicated as clearly as we would have liked,” it is not too late to communicate it more clearly.

5 Likes

That’s a good suggestion Ned. In fact, the first paragraph is likely due for an update to read from the standpoint that the January 1 date has now been met.

I am going to add this as an item for the first Steering Council meeting this year.

In fact, @pf_moore’s comment would be a good starting point:

As of 1st January, no new bug reports, fixes, or changes will be made to Python 2. Any changes that might have been made since 2.7.17 shipped haven’t yet been released, but as a final service to the community, python-dev will bundle those fixes (and only those fixes) and release a 2.7.18. We plan on doing that in April, because that’s convenient for the release managers, not because it implies anything about when support ends.

5 Likes

Can we add that same comment to the PSF blog announcement? That announcement does not mention the 2020-01-01 date, or that the 2.7 branch is now frozen. In fact it says the opposite:

Users are urged to migrate to a supported version of Python 3 in order to benefit from its many improvements, as well as to avoid potential security vulnerabilities in Python 2.x after April 2020.

…implying that security vulnerabilities discovered before April will be fixed.

1 Like

Sounds reasonable. We can take a look at that as well. Since the announcement on the blog was a press release, it probably would make sense to add a note box before or after the release text instead of changing any text of the press release.

4 Likes

I have asked the writer to make this update.

3 Likes

@mauve It’s a frustrating situation, I’m partly at fault since my team has been running communications on this, and I’m sorry you’re running into it. I do think the situation is fundamentally confusing and counter to most people’s expectations regarding what “sunset/EOL” and “support” mean. And I am in favor of your idea of freezing a 2.7.18 release candidate now to make our commitment to the January 1st sunset as concrete as possible (while respecting @benjamin’s prerogative regarding the 2.7.18 release date).

Here’s how the Python 2.7.18 situation works, as I understand it:

Python 2.7.18 is planned for release during PyCon North America in April 2020, per PEP 373 . More details:

January 1, 2020: Code freeze for Python 2.7.18

The “End of Life/sunset” of Python 2.7 will be January 1, 2020. Until January 1, 2020, the release manager for 2.7.x will be working on Release 2.7.18, the final release of Python. On January 1, 2020, the release manager will stop development and freeze the codebase (see python-dev discussion): from that date, there will be no backports to 2.7.18 from Python 3.

April 2020: Final Production Release of Python 2.7.18

It is expected that there will be no patches after the code freeze date for 2.7.18. (We do not expect any regressions to be introduced between the Python 2.7.17 release in October 2019 and the code freeze date of January 1, 2020.) Between January 1, 2020 and April 2020, the release manager will shepherd the release through the beta and Release Candidate process.

(I based this on discussions with core developers, such as this python-dev thread.)

As my team works to update multiple documents about the sunset, I’d like to know: were there any regressions introduced between the Python 2.7.17 release and the code freeze on 1 January?

All the commits to 2.7 are at Commits · python/cpython · GitHub and perusing that suggests no regressions, just normal bugfixes.

1 Like

I didn’t think of this at the time the original communication was being crafted, but the way I’ve thought about it lately is that the 2.7.18 release at Pycon 2020 is a “celebratory release”. It really is EOL’d as of January 1, 2020, but we can have the wake at Pycon with all of our friends.

I defer to @benjamin as to whether a 2.7.18 should actually be released, but the last we heard, he wanted to do it. So calling it a celebratory release to me gives the right message about what’s going to happen in April. It kind of reminds me of how we called 1.6.1 the Contractual Obligation release. :slight_smile:

2 Likes

I did not realize people would find this situation confusing or unpleasant. I ran the proposed release date by a few people in person at the core sprint, and they were all supportive. I didn’t think ±4 months would really matter much given the 10 year lifetime of 2.7. People who were going to port were already going to port. For those who aren’t, no extension of 2.7’s lifetime will be too small. (It would have been fine with me to formally extend the EOL 4 months, too, but we’d already announced that. shrug)

Basically, I thought it would be fun, and we all deserve a little fun after a decade.

7 Likes

I agree that people need fun, and catharsis, and no one more than you @benjamin. (Is cutting a release actually fun? I find releasing even my own projects relatively stressful.)

I agree that ±4 months makes no practical difference, only perceptual.

I joined my current firm in 2016 and took on the role of Python 3 champion then. By late 2018, when a bottom-up push had failed to make big inroads, the 2020-01-01 date became the headline part of what I told the big bosses to justify urgent effort (translating into some unknown multi-million dollar spend, as my CTO mentioned to me just before the holidays). The actual risks we identified were not attached directly to that date, of course.

The actual machinery of how/when Python 2 support ends doesn’t affect us at all, but it is pretty important to me that the big bosses don’t feel that they were hoodwinked.

1 Like

@mauve It doesn’t sound to me like the release plan is going to change. Emphasize with your bosses that the 2020 date extends beyond the CPython interpreter itself, to the third-party libraries you depend on, and so on. It was the right thing to port to Python 3.

2 Likes

I’m curious: what did you tell your bosses exactly? Just because Python 2.7 just stopped being supported doesn’t mean that it suddenly becomes insecure or dangerous to use in production. First because major security issues don’t pop up every month (and/or your particular use case won’t make you vulnerable), second because some vendors (RedHat?) might pick up maintenance on their side and update their packages as required.

The risk is more of a middle-to-long-term bitrot (and growing maintenance pains) rather than a short-term breakdown, so I’m unsure what level of “urgency” you argued for :slight_smile:

1 Like

@pitrou Many people consider software a risk if it isn’t supported. The core devs put out the message that support would end on 1/1/2020, and people listened. It’s a bit disingenuous to now ask what the rush was.

1 Like

Of course. My point is that it’s not a short-term risk. For more than 10 years, Python 2 has been receiving only bug and security fixes , so one may ask oneself: what is the likelihood of a business-threatening issue accross the Python 2 feature set appearing in the coming weeks or months? The reasonable answer is “almost zero” and the reasonable deduction is to not worry about migrating a month before or after the “deadline”.

Arguably, there was no rush, since the impending demise of Python 2 was known for years before. Just because a date isn’t set in stone yet doesn’t mean you shouldn’t worry. The rush just stems from irrational behaviour that jumps from one extreme (ignoring the issue entirely) to another (thinking wrongly that there is a sudden urgency).

Python 2 maintainers have invested enough of their volunteer time, they shouldn’t have to do an extra mile in order to alleviate illusory worries. While I appreciate that the April release date looks weird in relation to the 31 December end-of-maintenance deadline, it does not in itself create any risk or annoyance for any reasonable user.

1 Like

You deserve the fun after years of outstanding work. :smiley: