On Wed, Aug 29, 2018 at 10:26:29AM +0200, Adam Samalik wrote: > > Would it be necessary for us to pick one or the other here? IOW, > > whether the maintainer picked a specific date or a release, the EOL > > would resolve to a date. If they pick none, or explicitly choose > > 'rawhide,' then the artifact is essentially on a rolling window. > Yeah... that's a good point. Maybe having the ability to specify EOL as a > specific Fedora release or a date could be a good way forward. I like that. I don't think we should use "rawhide" to mean "rolling updates", because it also has the implication of "project devel stream". I know this was talked about a long time ago, but I'm not sure how it came down in practice: what's the tooling and workflow for moving users to a new stream when a stream reaches EOL? For example, Rawtherapee, which has a fairly traditional major/minor versioning scheme. Upstream provides downloads for old versions, but doesn't really support them. And, explicitly they say everyone should be on the latest stable release -- they didn't support a 4.x branch when 5.0 came out. >From a user point of view, the three streams I might want to choose from are: * Rolling always latest * Nightly dev builds! * A conservative stream which updates annually (or less!), ideally with backports for critical security bugs I know there was pushback against naming stream branches "stable", so is there a good _other_ way to offer this? If I name the stream branch "5" after the upstream major release, how do I get people in the first case seamlessly on to "6" when it comes out, whenever that is? -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader _______________________________________________ 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