Shortening the Python release schedule

Posted May 23, 2018 16:07 UTC (Wed) by Otus (subscriber, #67685)
Parent article: Shortening the Python release schedule

What's the point of frequent major releases? It's not like I can use features from release 3.X when it is released, but when 3.X-1 and earlier no longer have to be supported. And that's often years after the release of 3.X anyway, so half a year makes little difference.

(Unless it's a personal project in which case I can use them even while 3.X is still in beta.)

I'd rather see less frequent stable releases, with usable betas and features that see real world testing before they are set in stone. That means fewer versions to think about when e.g. wanting to support a large set of distros until their EOL.

Shortening the Python release schedule

Posted May 23, 2018 16:52 UTC (Wed) by smurf (subscriber, #17840) [Link]

The problem with setting new features in stone is that they frequently need to be refined by real-world usage. I'd rather see a release every year with more features that are explicitly marked as provisional, then frozen in the next release.

Shortening the Python release schedule

Posted May 23, 2018 18:23 UTC (Wed) by tlamp (subscriber, #108540) [Link] (6 responses)

> I'd rather see less frequent stable releases, with usable betas and features that see real world testing before they are set in stone. That means fewer versions to think about when e.g. wanting to support a large set of distros until their EOL.

The problem with this is: once people start using it in the wild it's more or less set in stone, you cannot really break with production stuff.
If you argue that they simply shouldn't not guarantee any API/Functional stability then I'd say that no one will really use it at a scale where it would become obvious if the new features and changes do actually well, it's a catch 22.

Shortening the Python release schedule

Posted May 23, 2018 18:55 UTC (Wed) by jhoblitt (subscriber, #77733) [Link] (5 responses)

Experimental features could be hidden behind a cli switch, some sort of pragma statement, or even adding `alpha` or `beta` on the keyword, module name, etc. as long as its not a parser change.

Shortening the Python release schedule

Posted May 23, 2018 22:30 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Doesn't matter. As long as it's out there and easily enabled, people are going to depend on it.

It's far better to have two distinct states: "feature present" and "feature not present" rather than a plethora of "present", "present, but broken", "present, but incompatible with the next version".

Shortening the Python release schedule

Posted May 24, 2018 23:04 UTC (Thu) by smurf (subscriber, #17840) [Link]

You forget "feature present, but saddled with random pain points which require arcane workarounds, yet are set in stone for the next three releases".

Shortening the Python release schedule

Posted May 24, 2018 18:00 UTC (Thu) by excors (subscriber, #95769) [Link] (2 responses)

Vaguely related to this: Around the time of HTML5, web browser developers realised that standards were good and it was a bad idea to pollute the global namespace with their own proprietary experimental features, so they used vendor prefixes to make it clear they were non-standard and not safe to be relied on by web sites, with the idea that eventually they'd be improved and standardised (based on experience from the experimental implementations) and have the prefixes removed. But it turns out that many web developers are irresponsible and will happily rely on those prefixed features in real production web sites, because all they care about is that it works today on their favourite browser, and then users of other browsers (or other versions of the same browser) blame their browser when sites look broken. That situation ends up with e.g. Firefox implementing webkit-prefixed features.

I guess the conclusion is: don't give developers a useful feature and then tell them not to use it, because they'll use it anyway, and either you'll have to support it forever or you'll go through the same pain as with any other compatibility-breaking change. "Experimental" and "deprecated" are meaningless.

Shortening the Python release schedule

Posted May 24, 2018 18:13 UTC (Thu) by jhoblitt (subscriber, #77733) [Link]

That's one possible interpretation... another is that when a project says a feature is unstable/experimental/beta it should mean it.

Shortening the Python release schedule

Posted May 24, 2018 23:00 UTC (Thu) by smurf (subscriber, #17840) [Link]

"Experimental" is meaningless when you have no way to find out whether the version you're talking to implements a feature or not. HTML's client browser identification is mostly meaningless for well-known reasons, there is no sane way to do "if FOO is implemented [reasonably correctly], use it, otherwise use this entirely different other method" in CSS, and don't get me started on the still largely abysmal state of end-to-end testing.

No such problems exist with Python versioning.