Building Software with Modularity

In the existing Fedora world, packages are maintained in branches that map to specific Fedora releases. Package repositories have branches e.g. “f27” for Fedora 27, “f28” for Fedora 28, etc.

There are no changes to the existing packager workflow. Maintaining release-specific branches and using the existing commands to build them keep working.

Modularity changes package branching to be version-focused.

Branching packages according to their major version as opposed to the distribution release brings more clarity — because we can see what lives in a branch, and removes source duplication — because there is one branch per version.

While this approach makes more sense from the software perspective, there is no longer a clear mapping of a package branch to a particular release. Modules are a way of defining this.

Modules define what package branches are built for which Fedora releases. One module can be built for multiple releases.

The above example produces three different binaries, one for each release. In case there are multiple architectures, three binaries will be produced (one each).

Multiple versions of packages can be built for one release by defining multiple modules. Users are able to choose which version they want to use on their system.

The above example produces two different binaries, each with a different Python version. Again, in case there are multiple architectures, two binaries will be produced for each one.

Modularity also leverages existing technologies such as containers to enable users to run multiple versions at the same time on one "machine."

Modules can be also be built against other modules to achieve more complex results. Client tooling always makes sure the right version is installed for a given context.

The above example produces two different binaries, each bound to a different Python version. Again, in case there are multiple architectures, two binaries will be produced for each one.