Call for testing: Snapcraft 8.6.0

Snapcraft 8.6.0 is in the latest/candidate and 8.x/candidate channels. The tentative release date is 2025-02-03T06:00:00Z.

Highlights include:

  • A new uv plugin for projects using uv.
  • A new Go Use plugin for setting up a workspace for Go modules.
  • The KDE Neon 6 extension can be used for core24 snaps.
  • The ROS 2 Jazzy extension is no longer experimental.
  • The how-to guides for common languages and frameworks have been rewritten and migrated to ReadTheDocs.

8.6.0 brings improvements to error message presentation and various bug fixes. For a complete list, see the changelog.

If you have any feedback or issues, please report them here or create an issue.

In the KDE Neon 6 extension design, do the content snaps have ABI versioning or do they follow a design like the Gnome extension which updates libraries continually on the same content base? (Since GTK3 is frozen and GTK4 is backwards compatible, this works well for Gnome).

The reason I ask is because I vaguely remember (and could be mistaken) that in Core 22, KDE Neon consumer snaps had to be regularly rebuilt with the new content snaps or they’d become out of sync, is this true and if so, is it still the case?

I’d like to give KeepassXC a dependency bump but the project isn’t keen on snaps in general so I’m keen to see if this implementation is viable with longer term support commitments (e.g., say 6-18 months without a rebuild)

@sgmoore, are you able to answer @James-Carroll’s question?

@James-Carroll Qt6 is not binary compatible with qt5, however qt6 promises binary compatible with its releases. https://doc.qt.io/qt-6/qt-releases.html#:~:text=Binary%20compatibility,built%20with%20the%20same%20configuration.

Thanks Scarlett, that covers the majority of the concern, I imagine then it’s a Gnome like model where the QT6 libs get upgraded across API in the same content snap but keep their binary level support which is great position to be in.

Snapcraft 8.6.0 has been released to stable.