On Wed, Jun 28, 2017 at 04:07:43PM -0400, Matthew Miller wrote: > So far, easy, I think. But what about modules like mine which are > collections of stuff? We could give them an arbitrary version and > increment that. Or, since this module will to follow the same 13-month > lifecycle of a base Fedora release, and make big changes in new streams > on the same cadence, it is tempting to use "f26", "f27" and so on. I > think, though, we want to avoid this, because it introduces a > conceptual overload that will become confusing and limiting. To what extent do we want to encourage "collections of stuff" modules? Numerically, most modules will likely to be designed to be installed as containers or flatpaks because that's how we handle conflicting dependencies. If you leave those modules out, then you really have the constraint that every package has to be in no more than one module. We can't have "Matthew's System Tools" and "Owen's System Tools" that are independently curated, because they can't be enabled on the same system. So my expectation is that the number of "collections modules" that have no strong connection to a particular upstream release process will be small and well defined - say Platform, Runtime, System Tools, and a few more. As such, I think it *would* be reasonable to say that they all are versioned at the same tempo and even keep the F<N> stream naming. But certainly there are other fine ways of doing it. > On the other hand, I want a label that tells people what to expect. > Langdon suggested that expected EOL might be a good way to do this. So, > I propose a convention that modules which do not correspond to single > specific versioned software all follow this convention: > Each such "collection" module MUST have one or both of the following: > > * A "latest" rolling stream (As above, this would be separate from > "rawhide", as "latest stable", but could update frequently and > arbitrarily.) > > * One or more streams corresponding to "end of life no earlier than", > in the format "YYMM". (Or "eolYYMM"? Or "eYYMM"? Or "uYYMM" for > 'until'? Or "fYYMM" for 'fedora' — which might make sense if we get > to my dream of mixing and matching with CentOS modules....) Hmmm, I see a couple of issues: * If we have 'apache' with a stream of 2.4 and 'GNOME Desktop' with a stream of 3.24, we can't have the stream name be the main way we convey EOL information. So then it's just confusing that for *some* modules the EOL is duplicated in the stream name. * The ability to change the EOL for a stream is quite likely useful - to decide it will have a longer support lifetime than originally planned. It would be even more confusing to have *incorrect* EOL's as the stream name. * Aren't people in July 2018 going to think f1806 is the current stream, not a two-year old stream? If we need arbitrary stream names that are consistent across Fedora, I think release dates would be a lot clearer than EOL dates - EOL dates seem more clever than useful. Owen _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
