On Thu, 2017-07-06 at 13:39 -0400, langdon wrote: > On 06/29/2017 11:30 AM, Matthew Miller wrote: > > On Thu, Jun 29, 2017 at 10:49:20AM -0400, Owen Taylor wrote: > > > 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. > > > > Langdon? Rebuttal? : > > I think containers are just a packaging type. In other words, whether > the "thing" is delivered as a docker container, flatpak, > rpm, something-not-though-of-yet, it is still the same module. This > is kind of the point, we want to disconnect the "content needed to > provide the service" from the "packaging mechanism to deliver the > content" (very loosely). As a result, we may see many different > module collections of stuff even if they are only being shipped as > containers (or whatever). I think you make different decisions depending on how you expect your module to be packaged/deployed. > So, I am not sure. I think Owen may have a point, but I think whether > we have "many" collections will evolve over time. However, I > definitely would not agree with the f<n> naming because why would it > need to "stream change" because of the fedora base? In other > words, a new stream indicates a new ABI/API but, I can tell you, no > matter how many versions of fedora go by, we are never gonna drop > emacs OR vi from the system-tools type collection so why would the > stream change? The module should be allowed to make decisions on its > content based on its own timescale not an arbitrary release boundary. > I think this applies to "collections of stuff" just as much as the > more obvious "single applications." But dropping emacs out of the system-tools collection would only be one form of ABI/API breakage. The following can also be breakages: * Upgrading a package, if the package changes its ABI, API, configuration files or command line options. * Adding a new package (the new package may conflict with packages from other modules with unpredictable results) And if module A depends on module B, and module B changes its ABI/API, that also effectively changes the ABI/API of module A in the general case. One of the main ways we have of handling this fragility is to distribute in a container (or container-like thing). If you design for distributing in a container, and always distribute in a container, then consumers can ignore a lot of things that happen inside the module. But for a module that is not containerized, that has a lot of packages in it, that depends on the Fedora Platform module, I think that the only realistic model that provides API/ABI stable streams is to release new streams often, probably in sync with the Platform model, and not change the streams much after release. Whether those streams are called F<n> or 201806 or whatever is a somewhat arbitrary choice. Owen _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
