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.
Fedora Project Leader
devel mailing list -- firstname.lastname@example.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org