11

What the absolute hell is going on with Python 3 releases?? Can anyone explain this

Python 3.5.9 - Nov. 2, 2019
Python 3.5.8 - Oct. 29, 2019
Python 3.7.5 - Oct. 15, 2019
Python 3.8.0 - Oct. 14, 2019
Python 3.7.4 - July 8, 2019
Python 3.6.9 - July 2, 2019
Python 3.4.10 - March 18, 2019
Python 3.5.7 - March 18, 2019

Comments
  • 16
    Have you heard of forking?

    The Linux kernel does this all the time. When you have a stable version you support it even though new versions are coming out. So once the 3.5 branch is stable you might backport critical fixes but not new features and release it as 3.5.8 over 3.5.6 but 3.7 could have shipped months ago.

    Debian uses an older kernel for stable typically but that kernel will continue to get backports for important bug fixes or functional issues (or new boot images for some updated pci device drivers or cpu support for new chips occasionally if it’s important) but those kernel updates continue to be released under the original major revision while life goes on for TOT kernel development.

    Pretty common release pattern
  • 11
    @FrodoSwaggins I'd rather call it branching, given that forking usually means to split off shit into a completely different project.
  • 4
    @FrodoSwaggins Why the hell would you need 3.5.4 when 3.6 is fully compatible? And why do you need to backport fixes to an old minor version for a *high level scripting language*??

    Are they breaking compatibility on each minor release or what? Continuing support for v2 makes sense. Continuing support for v3 *minor* versions seems like they have a serious problem somewhere...
  • 3
    @12bitfloat take a look at the support dates for each version. Each minor version (major.minor.patch) has it's own amount of time that it is supported. Basically they are their own releases.
  • 1
    @12bitfloat Because e.g. Debian will only backport security fixes into their stable branch. Then again, you don't want Debian maintainers to fudge around trying to extract security fixes because that was what lead to Heartbleed.

    The bullet-proof way is to release security fixes for old branches by people who actually know the software, i.e. the devs, and thus make sure that updates don't get fucked up.

    Also, Python may be high level, but the interpreter itself is written in C.
  • 4
    @Fast-Nop yes sorry bad terminology, you are right branching is the right word for it
  • 6
    @12bitfloat because it’s less risk to take the security updates than that and all the new features. You do it to avoid updating constantly to new untested versions in a mission critical environment. I’m not saying that’s always the right approach but but you have to weigh risks and make a choice.
  • 3
    As someone whos about to start learning python in school this post clears up some of my confusion. And an updoot for you, and an updoot for you....
  • 2
    At 3.8.0 they gave up and started to downgrade
  • 2
    @12bitfloat
    „Are they breaking compatibility on each minor release?”

    Yes.
    I’m not sure if that’s a language problem or the ecosystem, but the topic of compatibility is a horror in Python.
    And you cannot escape it by saying „fuck this Python crap, I’ll write my scripts in bash”, because many tools depend on it. For example, AWS cli is written in Python.
  • 1
    @matste Usually, it's about removing stuff that has been deprecated for years, and ignoring deprecation warnings in Python is a bad idea. Still, that will hit perfectly working, but unmaintained software.

    That's why languages like C and C++ have versioned standards, and every C compiler still supports the 1989 ANSI C standard via CLI setting so that you can compile decades old code.

    The catch is that the code has to be actually conforming to the standard from back then, which most old code isn't, so it will still break because of undefined behaviour that compilers back then didn't exploit, but current ones will.

    Sucks either way. :-)
Add Comment