Talking to self, but isn’t 7.x the point where all deprecates go south? Why yes it is. So, you had better look at your code again, hadn’t you? Yeah, well, but I’m using the binary! Ok, but ….
What about FreeBSD-like approach? e.g. SFOS 5.x-CURRENT development version for testing frequently updated, SFOS 5.x-STABLE with tested new things from -CURRENT and SFOS 5.x-RELEASE final version for users.
Yes, taking the step from QT version 5 to 6 takes a while, even though most users think of it as just needing a bit of magic, so the two versions would need to exist in parallel for a while. The applications are then allowed to transfer as soon as possible. Just switching from 5 to 6 overnight would be a perfect recipe for chaos, even with a schedule.
With the short cycles of a rolling release the apps wouldn’t need to wait too long for the next chance to walk the runway. There would be more chances to take the leap from 5 to 6 and the transition of all apps would probably conclude faster.
2 Likes
There doesn’t need to be separate channels for the stages of the process. The same could be achieved with changing an attribute for each app. Having just one channel quite possibly makes cooperation with third party developers easier too.