Well, /testing isn't really an option for something that's going to require a hundred other packages to be rebuilt. Shoving it in place is a better way to get feedback, knowing that if it turns out to be a disaster it's only going to take an afternoon to revert with the buildlist already prepared.

4 members found this post helpful.

I've had no end of problems with Frescobaldi. Its dependencies would only build, if I used updated versions (pygame and python3-pyQTWebEngine). These updated builds break Frescobaldi. While annoying, I can do lilypond in atom, which is actually better in the long run. I don't know if I'm the only person who'd be using it, though, since lilypond and Frescobaldi is kind of niche. (I did notice that Fedora is shipping python 3.10, and they do have an rpm for Frescobaldi.) It's annoying, but it's not a game-breaker, if we stuck with python 3.10.

I'm inclined to stick with 3.10, because the bugs will be worked out soon. (And am not sure how big a pain in the ass reverting so many packages would be.)

Your choice. For myself, I wouldn't go with a .0 release in the first place. I would leave it 3 months before upgrading, for packages to catch up. Once you have done it, stick with it would be my view.

Edit: If you are doing it in order to get feedback, I think best to say so in the ChangeLog so those of a conservative nature (or with a significant amount of stuff to recompile) can wait a couple of weeks before upgrading their installation of current upon it becoming "official".

Edit2: As an alternative I think you could put python-3.10 in testing, by including any dependent (and recompiled for 3.10) python programs within testing also. There was some package where you did something similar a year or so ago, but I can't remember what it was. Was it wayland, I am not now certain?

My view is that we are here now, so let's stick with it. Any pain that accompanies the change will be fairly short lived especially considering Redhat will be on board imminently.

For my own part, I have already put in the work regarding my own system; so on that account alone, would be very happy to stay the current course.

1 members found this post helpful.

All is said here :

https://docs.slackware.com/slackware:current

If true, all the more reason not to backtrack now.

(If not true - that is, were it to be the case that slackware has become a 'de facto' rolling release distribution because of the infrequency of "stable" releases, also all the more reason not to backtrack now.)

1 members found this post helpful.

Are we talking significant delays to 15 dropping with Python 3.10? That would kinda suck. What happens when we get everything working with Python 3.10 and some other new upstream release breaks something else? Truthfully, the only horse I have in this race is having 15 stable ASAP. I just fear that every delay will bring another reason to delay. At some point you just have to say good enough is good enough. Sorry - not a technical reason, but you did ask.

4 members found this post helpful.

Can you bump python3.10 to a 15.1 release? It would be nice to get back in the groove of a minor update every couple years or so.

As it stands right now 3.10 breaks a lot of projects and it's probably going to be a year before everybody updates. By reverting to 3.9 you can actually release earlier since 3.9 is known to work with existing projects. It has upstream support until 2025 and has gone through more testing than the latest version. Since you have the package list it shouldn't be a big deal to recompile against the known good python and ship that.

3 members found this post helpful.

I have a hundred extra things using python 3.10 , without issues , i think some people saying have issues are cause use obsolete python modules , probably cause SBo , need some time to go up with this.

In my opinion ,turn back now is an error , because final release not go to we launched tomorrow , we are only on rc1 , probably rc2 soon , but with time mantain 3.10 , and extra modules go up with new releases.

But its only my opinion.

4 members found this post helpful.

Well I just upgraded or rebuilt all of my third party package to 3.10. No issues so far. I had to added a couple of more dependencies out side of that things appear A okay.

If we go back, it is what it is.

1 members found this post helpful.

Totally agree. I have already recompiled all the packages for 3.10.
Let's think about the future, not the past!

1 members found this post helpful.

voted for 3.9, the upstream python ecosystem have to consider making things stable without the need of a bleeding edge python.

https://www.python.org/about/quotes/

voted for 3.10. It could mean some trouble with packages for a couple of months now (until other big distro like fedora drops 3.10, too), but it will also mean less trouble for an additional year when 3.9 will be obsolete.

2 members found this post helpful.

Voted 3.9
Am more for a 15.1 release with 3.10 next year or when it's ready for it

2 members found this post helpful.

I think the fact that one has to rebuild all X.Y "child" packages when upgrading the "base" package from X.Y to X.Y+1 indicates a design failure.
Having said that I spent a full day rebuilding my 6 "child" packages -- especially wxpython was recalcitrant.
Reverting (if that is what will be chosen) should be less work -- I hope.

2 members found this post helpful.