Petition: abandon plans to ship a 2.7.18 in April

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 https://github.com/python/cpython/commits/2.7 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:

Daniel,

If there is anything that I can personally do to reassure if needed, please feel free to contact me directly. Your advocacy within your company was a wise move, and your company will see benefits sooner because of your efforts.

I am truly sorry for any confusion on the message. There have been a lot of moving pieces this past year and a great deal of effort went into crafting information that would be encouraging and firm without being alarmist or inconsiderate. Everyone has done their best to communicate directly on the future of Python 3 and plans to wrap up CPython core developer work on Python 2. We will continue to iterate on communicating the specifics.

Warmly,

Carol

4 Likes

Very nice argument for closing of discussion