GNOME 3.38 is the latest version of GNOME, featuring changes from hundreds of contributors throughout the world. Have a look at what’s new! See the release notes at GNOME 3.38 Release Notes
Gotta say, I’m pretty excited about this release, especially since both pop-shell and material-shell are also stabilizing. Material-shell already added 3.38 support pre-emptively.
Let’s see how badly the other extensions are going to break. Once they work again, we can make a new release of gnome edition.
- gnome 3.38
- Material-shell as layout enabled in gnome-layout-switcher
- pop-shell as additional option in gnome-layout-switcher
- better btrfs support for calamares
- hybrid netinstall with calamares, letting you customize more freely what packages you want
I’ve been re-checking out Gnome after about 2-3 years on KDE (I have a workflow killing KWin bug right now) and, while I’m impressed at the progress made, I’m still disappointed that they’re still at a place where each update kills various extensions. That is why I left Gnome in the first place, it’s a very unfriendly DE to rolling systems. I would have hoped there would be come coordination and progress made by this point…
Extensions are not responsability of Gnome developer since mostly are made by Gnome users. Is a responsability of the gnome-extension-bla-bla follow the changes into gnome-shell. We can t do the guilty at Gnome.
Any prediction of when we will have this update in the stable version?
Depends a lot on the extension upstream projects. If our theming breaks, fixing it will take a week at most, but dash-to-dock might take longer if it breaks.
In calamares we have a working prototype for the hybrid installation, so I think that part is about 85% done. Btrfs improvements are about 35% done, that part is stalled until I have a computer to work with. But I don’t think btrfs is blocking issue, if everythingeelse work already, we can ship without it.
I’m thinking we might be ready for a release in a month or so, but this involves some uncertainties that we don’t have much control over. So, 2-6 weeks?
I hear you, but considering so many extensions are key for users and distros at this point, I would have imagined that coordination between major extension devs and Gnome proper would be more formalized, that’s all.
I view it like a programming language. Its up to me to test against nightly and fix things as the tests fail. I know extensions don’t really have automatic test suites nor some CI to test new commits.
Regardless, big extensions should be pulling & compiling gnome between updates so they can preemptively fix breaking changes.
Just came back into manjaro. To clarify, in 2-6ish weeks the newest version of mutter would be downloadable from pamac? I understand time estimates may vary.
In branches other than stable, newest gnome packages should become available much sooner than that. 2-6 weeks until gnome 3.38 works in the stable branch with all the extensions we ship by default.
Wonderful! Thank you for the information!
I Love Gnome not to mention I never used Gnome in any other Distro, Only With Manjaro
How can I see what version I’m on ?
Update why am I using 3.36.6 ? And how to update to 3.38 ?
3.38 is being tested in the unstable branch. Once we have ensured all the defaults that we ship with gnome work correctly, the update is pushed to stable. You can change to the unstable branch or just a wait for a few days.
Many thanks I will wait
me and unstable don’t work together well
Have switched to unstable because of 3.38
and “now” no problems detected on this machine related to 3.38
Are you sure? Not all extensions work properly (not sure about Manjaro though, I am saying based on my experience with Groovy).
On unstable everything used in the gnome-layout-switcher seems to have been working for a good while now.
It seems that the calamares improvements will not make it to the next release. However, we might be switching to wayland by default on non-nvidia systems.
all extensions installed by “Manjaro” / as default
Arch Linux Updater
User id in top panel
No errors with “journalctl -p err -b”