Okay, so, I decided to get my hands dirty with this to make sure my conceptual understanding stays in sync with the reality. And, it turns out we really do need a system-tools module. So, I'm going to make that. And in doing so, I ran into something I think is unresolved. An early decision needed when making a module is the label for the stream — that is, the dist-git branch it builds from. The convention is that within a stream, interfaces remain the same (just as now we expect big changes from release to release, not within f25 or f26). For modules which correspond primarily to a single piece of software (and associated stuff), it makes sense for the stream to match the major version of the software: module nodejs might have streams for 8 and 10, and httpd might have streams for 2.4 and 2.6. In fact, let's make that a guideline. I believe the existing https://fedoraproject.org/wiki/Module:Guidelines#Module_name.2C_update_stream_and_version doesn't have any rules, so let's make one. Specifically: * Modules which correspond primarily to a single application or versioned software stack (e.g. Apache HTTP 2.4 or Node.js v8) MUST use a stream label corresponding to the major version of that software (e.g. 2.4 or 8) * Such modules MAY additionally have a "latest" stream, which would be "rolling release" of the latest stable version (as opposed to master, which corresponds to rawhide and may be unstable). 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. 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....) Additionally and for all of our sanity, I suggest: * Valid module end-of-life dates are always either June or December, corresponding to the Fedora schedule of early May / late October base releases. So, f1806 or f1812, but not f1810 or f1901. I know there is some work on stream-to-stream upgrades in modularity; that work could take advantage of this convention. So, we'd have: httpd 2.4 httpd 2.6 nodejs 8 nodejs 10 sysadmin-tools latest sysadmin-tools f1812 sysadmin-tools f1906 Does this make sense? Do you have improvements or entirely better ideas? I have an alternate idea too: "collection" type modules would use arbitrary integer versions starting with 1 and increase only if the content undergoes a major switch. ALL module streams would contain EOL information after the version number separated by a ":". This EOL info would be a date as above, or the string "latest", _or_ the string "stable", indicating that no abi-breaking changes are expected ever and that we basically have no known EOL. With this alternate proposal, we'd have: httpd 2.4:stable httpd 2.6:latest (rolling as httpd 2.5 development leads to 2.6...) nodejs 8:f1912 (because that's upstream eol) nodejs 9:f1806 (if someone wants to do the work for a non-lts release) nodejs 10:f2106 (or maybe e2012) sysadmin-tools 1:latest sysadmin-tools 1:f1812 sysadmin-tools 1:f1906 -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
