On Mon, Aug 07, 2017 at 07:38:44AM -0400, Josh Boyer wrote: > > That way, users and admins aren't treated to an explosion of arbitrary > > days where action is needed to stay on a current stream. Instead, they > > can plan for annual upgrades as we do now. (I also expect the > > "platform" module to follow the current Fedora release cycle, right?) > I think that's short-selling users and admins ability to understand > what is supported and how to deal with it. Rather than knee-capping > modules, I think we should aim for a tool that easily informs users > how long each module is supported for. Admins already deal with > varying EOLs today on Enterprise products (e.g. RHEL is supported for > 10 years, but some Openstack versions are supported for 1 and some are > supported for 3). There's a big difference between "10 / 1 / 3 years" and "13 months / 18 months / 17 weeks / 3 years / 7 months / 280 days / 42 weeks / 1 year / 160 days / 12 days / 20 months / 13 months (3 months earlier than the other 13 months, though) / 6 months". I think 6 months granularity should be enough; and it doesn't have to be specifically tied to a given release cycle... it still could be 6, 12, 18, 24, 30. -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
