Petition: abandon plans to ship a 2.7.18 in April

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

This situation is at least a bit confusing.

The tracker still accepts new bug reports tagged for 2.7 and it appears that PRs can still be auto-backported to 2.7.

Yes because technically Benjamin could accept a fix for an earth-shattering bug and thus the mechanisms for handling such a case should probably be left around until 2.7 is converted into a git tag.

1 Like

Seconding @nedbat; the End Of Life date is and was a useful way for people to talk to their stakeholders about the continuing risk of continuing to use Python 2, the same way a “news hook” makes people pay more attention to any advice of continuing relevance.

Per this thread, I have now:

5 Likes