Why are the developmental tracks of many snaps hosting earlier packages than their counterparts?

For gedit, its track of latest/candidate is hosting a later version of its track of latest/edge, whereas for kate and ark, their tracks of latest/beta? are hosting earlier packages than their tracks of latest/candidate and latest/stable. Obviously, as defined by Using Tracks, the purposes of the default tracks are rather obvious, codified, and are used correctly by snaps such as vlc, telegram-desktop, and snapd. However, almost the entirety of some publishers’ catalogues (such as that of kde) are quite outdated for all of their tracks. Visit ark, okular, kwave, and spectacle for evidence.

Because lack of commitment to correct usage of tracks is so problematic for testers like me who want preview versions of lots of software to test them, and because this same lack of commitment is causing the snaps of very popular software to be so outdated that they are unusable (such as kwave and spectacle) this problem surely must be addressed, or else risk causing the experience of using the Snap Store to be quite unpleasant.

Therefore, surely this must be rectified somehow, perhaps the former problem by enforcement of an update to latest/beta, for instance, updating latest/candidate and latest/edge, if they are older (obviously this shall only be possible for software like Canonical’s GNOME packages, which utilise sequential numbering for their versions).

Having software that is cross-platform, if not at least the last two iterations of that software, is useless. I, like most that use this forum, desire snaps being the universal packaging format for GNU/Linux and Windows, but problems like this, being partially what has caused the adoption of the Microsoft Store to be so slow, must be overcome first.

1 Like