| Line 20: | Line 20: | ||
* Each version of a module has its own independent update stream associated with it. We avoid changing ABI or intentionally breaking forwards compatibility in any way within the update stream of a single version. | * Each version of a module has its own independent update stream associated with it. We avoid changing ABI or intentionally breaking forwards compatibility in any way within the update stream of a single version. | ||
* A module has a well known set of non-runtime dependencies which are not available in the same “repo” as the module itself. While it seems like this could be easily supported in the “for now” case, having this requirement makes sure we don't paint ourselves into a corner. | * A module has a well known set of non-runtime dependencies which are not available in the same “repo” as the module itself. While it seems like this could be easily supported in the “for now” case, having this requirement makes sure we don't paint ourselves into a corner. | ||
* A module has an API. In essence, the API is what makes the module. For example, if we had a Web server module, its API might be HTTP/2. We could provide that using httpd or nginx, and, next week, swap it, because the API is king, not the binaries inside. However, while we need to consider the API model, full support of this may not be necessary for the MVP. | * A module has an API. In essence, the API is what makes the module. For example, if we had a Web server module, its API might be HTTP/2. We could provide that using httpd or nginx, and, next week, swap it, because the API is king, not the binaries inside. However, while we need to consider the API model, full support of this may not be necessary for the [[https://en.wikipedia.org/wiki/Minimum_viable_product MVP]]. | ||
* A module comes with associated metadata such as lifecycle information (when does the module go end of life), who maintains it and to what support level, etc. | * A module comes with associated metadata such as lifecycle information (when does the module go end of life), who maintains it and to what support level, etc. | ||
* A module may include different versions of components than other modules. | * A module may include different versions of components than other modules. | ||
Note: We still don't know what kind of API we're going to define. So far we've only considered marking some of the provided binary packages as the module's "external API". That way we know what to test on updates and module consumers know what binary packages they can rely on. I'm not sure modules are ever going to provide abstract APIs. | |||
== Why do we call it modularity? == | == Why do we call it modularity? == | ||
Revision as of 13:07, 19 July 2016
Environment Modules are a concept unrelated to the Modularity initiative.
What is a module?
A module can be thought of as a dotted line we draw around a set of components that we declare a “thing.” It makes sense to think of a module as unit of measure larger than a traditional RPM.
OK, so what is modularity?
Modularity is an ongoing initiative in Fedora to resolve the issue of divergent, occasionally conflicting lifecycles of different components (modules).
What is a module’s lifecycle?
A module as a whole has its own lifecycle independent of any other module. Maintainers may decide to release multiple modules together on a common release schedule, but it is always possible to release modules independently when desired.
What are a module’s standard properties?
- A module has a unique name.
- Each version of a module has its own independent update stream associated with it. We avoid changing ABI or intentionally breaking forwards compatibility in any way within the update stream of a single version.
- A module has a well known set of non-runtime dependencies which are not available in the same “repo” as the module itself. While it seems like this could be easily supported in the “for now” case, having this requirement makes sure we don't paint ourselves into a corner.
- A module has an API. In essence, the API is what makes the module. For example, if we had a Web server module, its API might be HTTP/2. We could provide that using httpd or nginx, and, next week, swap it, because the API is king, not the binaries inside. However, while we need to consider the API model, full support of this may not be necessary for the [MVP].
- A module comes with associated metadata such as lifecycle information (when does the module go end of life), who maintains it and to what support level, etc.
- A module may include different versions of components than other modules.
Note: We still don't know what kind of API we're going to define. So far we've only considered marking some of the provided binary packages as the module's "external API". That way we know what to test on updates and module consumers know what binary packages they can rely on. I'm not sure modules are ever going to provide abstract APIs.
Why do we call it modularity?
We are trying to use an agnostic term so as not to indicate the specific nature of a module or a component. Modules can be big or small, low or high-level, brand new or very mature. As a result, please try not to ascribe too much meaning to the word module or component aside from being a slightly prettier and shorter version of “chunk of some stuff.”
Why are we pursuing this goal?
Well, there a a lot of reasons but, I think, the simplest is to try to disconnect the lifecycle of major components from each other so that they can grow and change at the speed that is appropriate to the component. Why does that matter? Well, that is a significantly more complex conversation and somewhat beyond the scope of this document.
I heard there were videos?
Yes, videos are delivered at the completion of every sprint and posted to a Fedora Modularity YouTube channel.
Where can I find out more?
The best place to start is where you already are: Modularity
As the wiki evolves, categories and new content will be added. Make sure not to miss the blog: https://communityblog.fedoraproject.org/
- Blog posts tagged with “Modularity” https://communityblog.fedoraproject.org/tag/modularity/
- Infra segment of the wiki
- Developer Notes segment of the wiki