On Thu, Jun 29, 2017, at 08:35 PM, Matthew Miller wrote: > On Thu, Jun 29, 2017 at 08:25:59PM +0200, Brian Exelbierd wrote: > > 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? > > I think it's likely that we would want an Apache 2.4 module to have a > longer-than-13-month-lifecycle. However, I don't want to commit to that > right now. This is actually a good argument for allowing EOL changes. > :) Sounds like this should be built-in and we should have tooling capable of alerting to lifecycle changes. I think it is a good plan to add a rule that barring massive issues, EOLs should only move out, not in. > > > So far, easy, I think. But what about modules like mine which are > > > collections of stuff? We could give them an arbitrary version and > [...] > > 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. > > Different versions of the various programs included may have changes to > command line parameters, big changes to output, etc. One command may > even need to be retired and possibly replaced with another. Having > versioned streams allows people to expect that they can use a certain > toolset without these surprises *inside* that stream. In this case, I feel like the system-tools module should be tied to a specific host/platform. It feels like a system-tools container. There is just too many moving parts for this to not be constantly spawning streams (even though these tools tend to be relatively stable). I think we should discourage this in general practice but have rules for getting permission to do it and ensure thee tooling can handle it. However, considering this from a different angle, a LAMP stack module, for example, might just need to make a certain API/ABI promise and then it could roll for quite a while. This would be without regard to the changes in the underlying software versions, as long as what was promised on the wrapper was still met. If this is the case then "collections" are no different from "single applications." regards, bex _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
