On Tue, Nov 27, 2018 at 4:39 PM Owen Taylor <otaylor@xxxxxxxxxx> wrote: > > One of the key parts of making a decision to delay/skip F31 is > figuring out, ahead of the decision, what the expected experience is > for users and packagers. Does F30 have normal stability, or do we try > to keep users happy by moving things forward with ad-hoc updates and > cross-our-fingers and hope nothing breaks? > > I tend to think about this in terms of GNOME - would we rebase to > GNOME 3.34 in the middle of F30 or not? But there's a lot of other > pieces of software where similar considerations apply: container > tools, cockpit, NetworkManager, etc. > > And if we did do updates like that, would we consider respinning media > and making a "F30.1"? > > Owen Yes, I could get behind this idea - it sounds like a tick-tock model, with yearly major releases (tick), and one smaller maintenance upgrade inbetween (tock). That would basically result in fedora 2019.0 and 2019.1 releases, possibly with an automatic upgrade from .0 to .1 (since it's a small update). This approach would also ~double the lifetime of a major fedora release (if we want to keep two active major releases plus rawhide), or reduce the number of active fedora releases by one (if we keep the overall lifetime the same). Fabio > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
