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. :) > > 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. -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
