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(a)fedoraproject.org>
Fedora Project Leader