On Wed, Jun 28, 2017, at 10:07 PM, Matthew Miller wrote: > 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). Does this mean that a module built primarilly from a single application does not have a 13 month fixed lifecycle? I hope this is true because, in my mind, one of the things a module is promising is that some form of API/ABI won't break. When I hear Apache-2.4, I think, "this module is apache 2.4. I don't need to know the z-release because I know the 2.4 API won't be broken." I also think that having an arbitrary EOL for the stream of 13 months even though Apache 2.4.x will continue to be available after that is odd. What changed causing the need to EOL the stream I was on and replace it with a new Apache-2.4 stream? Have I just misunderstood modules? > 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. What is changing from one collection version to the next? What is my understanding of what is in the box at any moment in time? If the module is tied to a specific host/platform then I would expect it to carry that information in the metadata (see below). If it isn't, what change prompts a new version? I think that is what we need to define as well. > 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....) I'll be brief as some others have touched on this already, but, as jwb said, "Modularity is new. It's different. It will be hard at first. Let's not hamstring ourselves from the start." Along these lines, I'd like to see us encode less in the name and more in the metadata. I'd like our tools to be metadata consumers, not name parsers. I believe it is reasonable to make some query the stream/module/object and not just expect to read the information they want in an FTP listing. For all of these reasons, I think streams could just be X-version and X-latest. regards, bex > > 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
