6 ms·

I was curious how this changed from their previous process. It looks like they've historically averaged about once per 18 months for the past few releases.

• donarb 7y ago
  In the PEP 602 document (https://www.python.org/dev/peps/pep-0602/ https://www.python.org/dev/peps/pep-0602/) they state that the previous schedule was roughly 18 months. One reason they wanted to forgo this time frame is that there is pressure to stuff many changes into each release because missing the deadline means waiting another 18 months.
• vnglst 7y ago
  I'm wondering why Python has such an slow release cycle? There are new Node.js releases on a weekly (and sometimes daily) basis. Why not ship any improvements you have immediately to the users?
  • jrumbut 7y ago
    I like a more stately release process for a language (compared to applications where I do love frequent releases). Stability and predictability are important. Porting code to new versions is not something I want to be continuously working on, and increasing the number of OS/language/library combinations to debug is painful. Once a year sounds about right, with important bug and security fixes being pushed out when needed.
    • 3JPLW 7y ago
      Naive question: does Python follow SemVer?
      • icegreentea2 7y ago
        No. Python versioning pre-dates semver. That said, point releases (like 3.7.2 vs 3.7.1) are generally considered backwards compatible - they are suppose to "just be" bug fixes and security fixes. 3.x to 3.x+1 has no guarantees about backwards compatibility.
        • eesmith 7y ago
          It's also very hard, in any language with "eval", to support new language features and backwards compatibility. try: eval("async") except NameError: print("pre-3.7") except SyntaxError: print("3.7 or later") Similarly, eval("a@b") gives a NameError on newer Pythons, and SyntaxError on older.
          • 3JPLW 7y ago
            I don't think that has anything to do with `eval`. It's just hard to do with a dynamic language. And that's not to say it shouldn't be attempted!
            • eesmith 7y ago
              "Eval" is one way to implement a dynamic language, so I'm confused by why you seem to write those as very distinct concepts. Is it correct to interpret your last line as saying that Python should support SemVer? If so, the only way to get SemVer is for every release to increment new major number, as every single one has backward incompatible behaviors going through eval. eval("a:=1") - SyntaxError before 3.8 eval("async=1") - SyntaxError starting with 3.7 eval("1_0") - SyntaxError before 3.6 eval("a@b") - SyntaxError before 3.5, NameError after It's true there are other ways for a dynamic language to trigger backwards compatibility issues than by going through eval(), but my goal was to give concrete examples of how difficult it would be for Python to make guarantee about backwards compatibility because eval() does exist.
              • 3JPLW 7y ago
    • vnglst 7y ago
      Maybe releasing more often could improve stability and predictability? Isn't it like they say: if it hurts, do it more often. This is also what the JavaScript community is moving towards, both for the language specs where new features are "released" once they're ready (see: https://2ality.com/2015/11/tc39-process.html https://2ality.com/2015/11/tc39-process.html) and their respective implementations in browsers and Node. As far a I can tell, those release processes (with many millions of users and full backwards compatibility going back to early beginnings of JavaScript) are neither unstable nor unpredictable.
      • icegreentea2 7y ago
        Things to consider. Javascript has a much stronger separation between language specification, standard library, and runtimes than Python. The Javascript standard library is famously sparse, and there are multiple runtimes with significant usage and development. Python on the other hand has a much larger standard library to maintain, and effectively has only one runtime (yes, I love PyPy too, but realistically 99+% of runtimes are CPython). And they are all implemented by the same group. The mechanics of quickly releasing language level changes, or standard library changes, or runtime changes in Python I feel do not fully map to that of the Javascript experience. The language usage models are also very different. In the majority of Javascript use cases, I feel that you either fully control the runtime and code (like in a server, or something like Electron), or you have a fairly intelligent server determining what the runtime environment is and providing backwards compatibility shims for you (polyfills on browsers). Certainly something like the first case exists for Python, but certainly the tooling for deploying onto arbitrary runtime and capabilities doesn't quite exist. Indeed, the Python packaging story is one of its weaknesses right now. Python certainly could be made into something where the Javascript like process would work, but I'd certainly agree with anyone in the core Python development team who believed that they thought their energies could be focused better on other priorities.
        • vnglst 7y ago
          That's a great answer, thanks. I think it's really interesting to see how differently both open source projects are managed and maintained.
    • nicoburns 7y ago
      I think release frequency and stability are pretty orthoganal. I haven't had a node upgrade break my code since 0.8 (which was obvious a pre-1.0 release). Likewise, Rust releases every 6 weeks and it's rock solid.
    • droithomme 7y ago
      I like bug fixes and security updates the day they are ready. Language updates that change the language I prefer once every 25-40 years.
  • coldtea 7y ago
    Because people depend in Python for real work, and are not used to the platform play havoc with them and change under their feet every few months...