On Tue, Jul 05, 2022 at 01:17:39PM +0200, Miro Hrončok wrote: > Hello, > forwarding this message to Fedora. > > Will know more by the end of this week -- we might need to consider > reverting back to Python 3.10 if we don't want to ship Fedora 37 GA > with a beta version of Python :( Is there a reason why shipping a beta version of Python would be bad? I've been using it on my main development machine for a few weeks and for the (fairly limited) Python stuff I do it seems to be fine. It'd be a problem if it was causing bugs. Rich. > Fedora 37 mass rebuild is planned for 2022-07-20 -- I will make sure > we know what to do by then. > > Too bad we haven't known this before we started the 3.11 mass rebuild :/ > > > -------- Forwarded Message -------- > Subject: [Python-Dev] [Release] Status of Python 3.11 release > Date: Mon, 4 Jul 2022 23:36:39 +0100 > From: Pablo Galindo Salgado <pablogsal@xxxxxxxxx> > To: Python Dev <python-dev@xxxxxxxxxx>, python-committers > <python-committers@xxxxxxxxxx> > > > > Hi everyone, > > # TLDR > > We may be pushing the final release until December if the stability > of Python 3.11 doesn't improve. > > # Long Explanation > > Unfortunately, we cannot still release the next Python 3.11 beta > release (3.11.0b4) because we still have a bunch > of pending release blockers. Unfortunately, this is still after > several preexisting release blockers have been fixed, > some of them being discovered after I sent my last update. These are > the current release blockers: > > https://github.com/python/cpython/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3Arelease-blocker+label%3A3.11+ <https://github.com/python/cpython/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3Arelease-blocker+label%3A3.11+> > > We also have some deferred blockers (some of them should actually be > release blockers): > > https://github.com/python/cpython/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3Adeferred-blocker+label%3A3.11 <https://github.com/python/cpython/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3Adeferred-blocker+label%3A3.11> > > Due to this and the fact that we are already 3 weeks delayed in the > release schedule, the current stability of Python 3.11 is not as > good > as it is supposed to be at this stage of the release schedule and > more testing from end-users and library authors is required. After > discussing with the Steering Council, we are considering delaying > the final release until December to allow for two more beta > releases. > This is how we are going to proceed: > > * If the current release blockers are not fixed by the end of this > week, two more betas will be released (1 month per beta) and > we will *definitely* delay the final release until December. > * If the current release blockers are fixed we will proceed to > release Python 3.11.0b4 on Monday. We will target the current > release > date (Monday, 2022-10-03) but if more release blockers that affect > fundamental parts of the Python interpreter or the standard > libraries > are raised, the release team will still consider adding two more > betas nd pushing the final release to December. > > One of the goals that we are going to try to achieve from the > release team is that no substantial code changes are added between > the last > beta and the first release candidate. This is so all the fixes that > affect fundamental parts of the interpreter or the standard library > can be > tested by end-users before the first release candidate is released > (and not with it). This is also partially because once we release > the first release > candidate, the ABI will be frozen and certain kinds of fixes will be > more complicated. > > Hopefully, this addresses some of you that have reached out with > concerns over the stability of Python 3.11 and the release schedule. > > I understand that delaying the release until December will > complicate things for some Linux distributions and will affect end > users and redistributors > targeting the original release, but please understand that our > responsibility in the release team after all is to guarantee a > stable final release > above all and unfortunately, we don't currently have the confidence > that we would like given the current state of the release process. > > Please do not hesitate in reaching out if you have any questions or concerns. > > Thanks, everyone for your help and understanding and thanks a lot to > all of you for your great work! > > Cheers from cloudy London, > Pablo Galindo Salgado > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
