Why was Python 3.7.7 released after Python 3.8.2?
When its the same version, meaning python2 and python3
It says so on the website: https://www.python.org/downloads/
Each minor release (i.e. <major>.<minor>.<patch>) introduces new features and in some cases makes backwards incompatible fixes. That means that someone might need to still stay on 3.7 - but you still might want to fix bugs in the 3.7.x line of releases.
That bug fix release for the 3.7 line can then be released after any release to 3.8 (or any other 3.x release for that matter, if it's something only related to that minor release). In general older minor releases are abandoned after a while, and receive no further patches.
From the release notes for Python 3.7.7:
Python 3.8 is now the latest feature release series of Python 3. Get the latest release of 3.8.x here. We plan to continue to provide bugfix releases for 3.7.x until mid 2020 and security fixes until mid 2023.
Python 3.7.7 is the latest bugfix release of Python 3.7.
There is one more planned release for the 3.7.x branch, 3.7.8. After that only security fixes will be applied until 2023.
3.7.8 candidate 1: 2020-06-15 (expected)
3.7.8 final: 2020-06-27 (expected)
Imagine that you have a farm and a tractor, a plow on it and some workers. You want to improve performance in your farm so you buy a new tractor with new features and a new and better plow. Some workers may like to work with it but some others may prefer the classic one because they simply feel more comfortable using it! So the classic lovers want to get a better and bigger plow. So because you are a kind farmer, you upgrade the classic plow as you have eyes on the new tractor.
Now consider farmers as python language developers, farmers as programmers, tractor as python and plow as python versions.
Hope that was useful. :D
Related
I need to install Python 3.8 on a Windows computer and hope to use the latest minor version of 3.8.12. The official release web page provides tarball files of the source code but no Windows installer. Python 3.8.10 provides Windows installers, but it is not the latest version.
I am wondering:
Why v3.8.12 does not provide any Windows installer?
If we want to use v3.8.12, what can we do?
I appreciate your help and suggestions.
https://devguide.python.org/#status-of-python-branches provides a summary of the various release statuses.
features
new features, bugfixes, and security fixes are accepted.
prerelease feature fixes, bugfixes, and security fixes are accepted
for the upcoming feature release.
bugfix bugfixes and security fixes are accepted, new binaries are
still released. (Also called maintenance mode or stable release)
security only security fixes are accepted and no more binaries are
released, but new source-only versions can be released
end-of-life release cycle is frozen; no further changes can be pushed
to it.
Python 3.8 is currently in security mode, so only source releases (and no binary installers) are provided from Python itself.
As the page you linked to says,
According to the release calendar specified in PEP 569, Python 3.8 is now in the "security fixes only" stage of its life cycle: 3.8 branch only accepts security fixes and releases of those are made irregularly in source-only form until October 2024. Python 3.8 isn't receiving regular bug fixes anymore, and binary installers are no longer provided for it. Python 3.8.10 was the last full bugfix release of Python 3.8 with binary installers.
Python 3.8.10 was the last release at the bug fix stage, and so the last for which Python officially provided binary installers. If you want a binary installers for 3.8.12, you'll have to either make one yourself from the source or find someone else who has done it or will do it for you.
You can easily build it by following the instructions.
Add the resulting PCbuild\win32 directory to PATH and you are good to go.
Does Long-term surppot version and stable version exist in Python 2.x or Python 3.x version? And if so, what are the criteria?
not currently
see PEP407 status: "deferred"
https://www.python.org/dev/peps/pep-0407/
It doesn't use same wording but on 7. November, 2019 PEP602 was accepted which introduced release cycles. You can find more info about current versions and their states here.
At present(May 2013), there are three release versions, all released on may 15
python 3.3.2
python 3.2.5
python 2.7.5
I can understand the need for 2.x and 3.x branches but why are there seperate 3.3.x and 3.2.x versions?
In this link is says The current production versions are 2.7.5 and 3.3.2..
And if you look here it says:
Python 3.2.5 was released on May 15th, 2013. This release fixes a few regressions found in Python 3.2.4, and is planned to be the final 3.2 series bug-fix release.
So you should use 2.7.5 or 3.3.2, but if you need (I don't know why) 3.2.* you have a bug-fixed version.
As wim points out, 3.2.5 is not a current production version, but I assume you're wondering why there were three versions released on 15 May 2013? That is why is the 3.2.x branch still being maintained?
Remember that each 3.n step introduces new features while 3.n.x releases are fixes to existing versions. 3.2.5 is thus a set of bugfixes to 3.2.4 while the 3.3.x branch includes new features not present in 3.2.4. Because new features are, inherently, more likely to introduce new bugs, the maintenance of the older branch allows you a higher stability choice if, for example, you're just putting together a new public release of your webserver and don't want to risk new bugs being introduced by the current branch.
This is a question of python's versioning strategy. Quote from python's wikipedia article:
CPython's public releases come in three types, distinguished by which
part of the version number is incremented:
Backwards-incompatible versions, where code is expected to break
and must be manually ported. The first part of the version number is
incremented. These releases happen infrequently—for example, version
3.0 was released 8 years after 2.0.
Major or "feature" releases, which are largely compatible but introduce new features. The second
part of the version number is incremented. These releases are
scheduled to occur roughly every 18 months, and each major version is
supported by bugfixes for several years after its release.
Bugfix releases, which introduce no new features but fix bugs. The
third and final part of the version number is incremented. These
releases are made whenever a sufficient number of bugs have been fixed
upstream since the last release, or roughly every 3 months. Security
vulnerabilities are also patched in bugfix releases.
So, 3.3 compared to 3.2 introduced new major features, that's why it's in a separate "branch".
Also see:
Python 3.2 Release Schedule
Python 3.3 Release Schedule
Python 3.4 Release Schedule
You should read bit about version numbers. The last digit means, simplified, no new features only bug fixes. So folks who use Python 3.2 can installed a newer revision without changing anything in the behavior of Python.
Is there a known date/timeframe when python 2.7 will not be supported any more in favor of python 3?
As of 13 Apr 2014, from http://hg.python.org/peps/rev/76d43e52d978 (PEP 373, Python 2.7 Release Schedule):
The End Of Life date (EOL, sunset date) for Python 2.7 has been moved
five years into the future, to 2020. This decision was made to
clarify the status of Python 2.7 and relieve worries for those users
who cannot yet migrate to Python 3. See also PEP 466.
In May 2010, Word of God was that patchlevel releases for Python 2.7 will probably be made for at least 6 years.
So, maybe 2016, probably later.
Edit: Pushed back to 2020. See the revision to PEP 373, linked to in other answers.
Recently, that date has been updated to January 1, 2020.
see https://pythonclock.org/
you should read this carefully (ref : https://news.ycombinator.com/item?id=7582300 ):
There are a lot of comments here from people who aren't on the python-dev list and don't really understand what this diff actually means.
The core developers are not required to maintain 2.7 post-2015, and most of them won't be involved in it. That part hasn't changed.
What is happening is that Red Hat is preparing to cut a RHEL 7 release, which AFAIK depending on how much you pay them they support for 13 years. So they will need to figure out how to support 2.7 themselves at least through 2027.
Here is where I am reading between the lines. RH are well within their right to fork Python and keep their maintenance patches to themselves and their customers (Python's not copyleft). But, they are nice guys and so maybe they are willing to upstream their changes at least for awhile if there is still a Python project willing to accept them. Again, this is my speculation based on the ML discussion, not what RH has actually said they will do.
An analogy can be made to Rails LTS, a commercial fork of Rails 2.x that patio11 was involved in [0]. Inevitably somebody is going to step in to support 2.7, and so let's see what we can do to avoid a situation where the only way to keep running 2.7 is to subscribe to RHEL.
Meanwhile, there are some large companies that use 2.7 extensively on Windows (e.g. Enthought, Anaconda) and the thinking goes that somebody can probably be found to produce a Windows installer once in awhile, assuming that Python.org will still host a download.
So really what is happening here is not very exciting. The core committers aren't doing anything different than leaving the project as originally planned. What is happening is that they will leave the lights on in the source control repository and on the FTP server, so as to capture the free labor from people at large companies who have an interest in continuing to support 2.7.
The alternative is that RH and other vendors create proprietary and expensive forks of Python 2.7. That may end up happening anyway, but it will take longer for your employer to notice you should stop contributing your patches back if binaries still appear on python.org and you don't have to ask IT to set up SCM and a bug tracker, etc.
This article says: “When 2.7 is released, the 2.x line will move into five years of a bug fix-only mode.”
So, as far as I see, Python 2.7 was the last 2.x feature-adding release, and though found bugs are going to be fixed (for some time), new features only go to 3.x releases.
PEP 373 (Python 2.7 Release Schedule) is the official source for the kind of information you asked for.
It currently says "Planned future release dates:"
2.7.7 May 2014
2.7.8 November 2014
2.7.9 May 2015
beyond this date, releases as needed
Also, it says "The End Of Life date (EOL, sunset date) for Python 2.7 has been moved five years into the future, to 2020."
Edited in April 2014, according to http://hg.python.org/peps/rev/76d43e52d978
The Python Developer’s Guide lists the "Status of Python branches" from version 2.6 up to the current version, including their current support status with End-of-life dates.
Currently supported (bug + security fixes):
Python 3.8 (current master/development branch)
Python 3.7
Python 3.6
Python 2.7 (until 2020-01-01)
Security fixes only:
Python 3.5
Python 3.4
Python 2.7 wil be around forever. There is too much old code that uses it that no one wants to rewrite. There is already a fork called Tauthon, but we may see others if this pointless deadline gets real.
In our group we primarily do search engine architecture and content integration work and most of that code base is in Python. All our build tools and Python module dependencies are in source control so they can be checked out and the environment loaded for use regardless of os/platform, kinda similar to the approach virtualenv uses.
For years we've maintained a code base compatible with Python 2.3 because one of the commercial products we use depends on Python 2.3. Over the years this has caused more and more issues as newer tools and libraries need newer versions of Python since 2.3 came out in ~2004.
We've recently decoupled our build environment from dependencies on the commercial product's environment and can use any version of Python (or Java) we want. Its been about a month or so since we standardized on Python 2.6 as the newest version of Python that is backwards compatible with previous versions.
Python 3.0 is not an option (for now) since we'd have to migrate too much of our code base to make our build and integration tools to work correctly again.
We like many of the new features of Python 2.6, especially the improved modules and things like class decorators, but many modules we depend on cause the Python 2.6 interpreter to spout various depreciation warnings. Another tool we're interested in for managing EC2 cloud cluster nodes, Supervisor doesn't even work correctly with Python 2.6.
Now I am wondering if we should standardize on Python 2.5 for now instead of using Python 2.6 in development of production environment tools. Most of the tools we want/need seem to work correctly with Python 2.5. We're trying to sort this out now before there are many dependencies on Python 2.6 features or modules.
Many Thanks!
-Michael
I wouldn't abandon 2.6 just because of deprecation warnings; those will disappear over time. (You can use the -W ignore option to the Python interpreter to prevent them from being printed out, at least) But if modules you need to use actually don't work with Python 2.6, that would be a legitimate reason to stay with 2.5. Python 2.5 is in wide use now and probably will be for a long time to come (consider how long 2.3 has lasted!), so even if you go with 2.5, you won't be forced to upgrade for a while.
I use Python 2.5 for all my development work, but only because it's the version that happens to be available in Gentoo (Linux)'s package repository. When the Gentoo maintainers declare Python 2.6 "stable"*, I'll switch to that. Of course, this reasoning wouldn't necessarily apply to you.
* Python 2.6 actually is stable, the reason it's not declared as such in Gentoo is that Gentoo relies on other programs which themselves depend on Python and are not yet upgraded to work with 2.6. Again, this reasoning probably doesn't apply to you.
My company is standardized in 2.5. Like you we can't make the switch to 3.0 for a million reasons, but I very much wish we could move up to 2.6.
Doing coding day to day I'll be looking through the documentation and I'll find exactly the module or function that I want, but then it'll have the little annotation: New in Version 2.6
I would say go with the newest version, and if you have depreciation warnings pop up (there will probably be very few) then just go in a find a better way to do it. Overall your code will be better with 2.6.
To me the most important to stick with python 2.5+ is because it officially supports ctypes, which changed many plugin systems.
Although you can find ctypes to work with 2.3/2.4, they are not officially bundled.
So my suggestion would be 2.5.
We're sticking with 2.5.2 for now. Our tech stack centers on Django (but we have a dozen other bits and bobs.) So we stay close to what they do.
We had to go back to docutils to 0.4 so it would work with epydoc 3.0.1. So far, this hasn't been a big issue, but it may -- at some point -- cause us to rethink our use of epydoc.
The 2.6 upgrade is part of our development plan. We have budget, but not fixed schedule right now.
The 3.0 upgrade, similarly, is something I remind folks of. We have to budget for it. We won't do it this year unless Django leaps to 3.0. We might do it next year.
I think the best solution is to give up the hope on total uniformity, although having a common environment is something to strive for. You will always will be confronted with version problems, for example when upgrading to the next best interpreter version.
So instead of dealing with it on a per issue base you could solve this problem by taking a good look on your release management.
Instead of releasing source, go for platform depending binaries (besides the source distribution).
So what you do is that you define a number of supported CPU's, for example:
x86-32, x86-64, sparc
Then which operating systems:
Linux, Windows, Solaris, FreeBSD
For each OS you support a number of their major versions.
Next step is that you provide binaries for all of them.
Yes indeed this will require quite some infrastructure investment and setting up of automatic building from your repositories (you do have them?).
The advantages is that your users only have 'one' thing to install and you can easily switch versions or even mixing versions. Actually you can even use different programming languages with this approach without affecting your release management too much.