I would like the following tracks to be created for the qt-framework snap
These track the supported and legacy X.Y QT versions and drop the patch numbers at the end. Version compatibility can be found here, but varying patch versions does not break compatibility forward or backward between binaries. The tracks will follow the latest available patch numbers.
QT releases LTS versions (5.15, 6.2, 6.5) that are “supported” for 3 years as well as non-LTS versions that have a one year cycle.
Per Process for aliases, auto-connections and tracks, we need a 1-week voting/discussion period, so I’ll check back on the discussion and votes in a few days.
I have three questions before casting my vote.
- What’s qt-framework’s release cadence, how often is a new major version (potentially requiring a new track) released? Is this documented somewhere by upstream?
- Is there some commitment from upstream on maintenance of old versions? e.g. is the “5.15” release still supported with security updates? Will it continue to be supported now that e.g. “6.2” is out, and for how long?
- Are new versions backwards-incompatible? I see from the link you posted that new major releases are backwards-incompatible but minor ones are not it seems. Meaning, if I was running “6.2” and try to install “6.4”, will that just work, or do I need to migrate my data/configuration, or will things break horribly?
Also, to clarify, the exact snap name you want these tracks to be created for is
After some deliberation, theres some changes that need to happen to snapd before I can move forward with these tracks. I do howerver, want these tracks made for the
qt-framework-sdk snap. I can make a new post if that is required. To answer your questions:
Minor releases are released every year while LTS’s cover every 3 years. Major versions I don’t believe are documented anywhere, but heres some more general releasing info from their wiki.
There is some commitment in upstream patch releases as KF5 is based on this. The open-source versions lag a little bit behind generally. I believe 5.15 is no longer supported, but many, many applications still use it and as a result, need to have that supplied until the code can be refactored.
I think the answer to this comes from the doc I linked originally: “However, in order to improve Qt it is sometimes necessary to break compatibility.” Theoretically, it should, but often thats not how it plays out in practice.
Breaking backwards compatibility is a good use case for using tracks. +1 from me as a reviewer.
The requested tracks have been created for the
qt-framework-sdk snap. Once you’re ready, please re-request here (preferably) or in a new post, the tracks you want for the
@odysseus-k Can I get the track 6.7 created for the
6.7 track has been created.