#112 Discussion: Module lifecycles
Opened a month ago by asamalik. Modified 2 days ago

Discussion for the #3 Module life cycles epic.

This is very packager focused. I want to design the packager experience first before diving into implementation details.

Traditional branching and lifecycles:

There is a branch for every release. To ship a specific version of a package for a specific Fedora release, you simply push the right source into the right branch in dist-git.

Dist-git branches:

  • nodejs 8 source -> "f27" branch
  • nodejs 8 source -> "f28" branch
  • nodejs 10 source -> "f29" branch
  • nodejs 10 source -> "master" branch

What's available:

  • Fedora 27: nodejs 8
  • Fedora 28: nodejs 8
  • Fedora 29: nodejs 10
  • Fedora rawhide: nodejs 10

Lifecycle expectation: Package is being branched for new releases and built forever until retired in rawhide.

Very simple, yet limited: you can't have multiple versions in one release. And you might be pushing the same source into multiple branches.

Modular branching and lifecycles:

There are stream branches — structured in any way the packager desires — but typically based on major versions. You push each version only once to its respective branch. But what goes where?

Modules are a way of defining what goes where. One version can go to multiple Fedora releases, and one Fedora release can receive multiple versions. And defaults are a way of deciding which of the multiple version is available as a default — so traditional workflows keep functioning.

Dist-git branches:

  • nodejs source 8 -> "8" branch
  • nodejs source 10 -> "10" branch

NEW: Module definitions:

  • nodejs 8 -> Fedora 27, Fedora 28, Fedora 29, Fedora 30 which is rawhide now
  • nodejs 10 -> Fedora 28, Fedora 29, Fedora 30 which is rawhide now

NEW: Default definitions:

  • Fedora 27: nodejs 8
  • Fedora 28: nodejs 8
  • Fedora 29: nodejs 10
  • Fedora 30 (rawhide now): nodejs 10

What's available:

  • Fedora 27: nodejs 8 by default
  • Fedora 28: nodejs 8 by default, but also nodejs 10
  • Fedora 29: nodejs 10 by default, but also nodejs 8
  • Fedora rawhide: nodejs 10 by default, but also nodejs 8

However, we don't want you to manually list releases in your module definition and requiring you to update it every time there is a new release.

That's why you can declare:

  • nodejs 8 -> all Fedora releases
  • nodejs 10 -> all Fedora releases

But what to do when nodejs 8 reaches its EOL (end of life)? We still don't want to ask you to suddenly list "all Fedora releases up until now" in the module definition so it stops building for the next one. We need a way for you to define an EOL so the build system can figure this out automatically.

We also want to keep the Lifecycle expectation: Package is being built forever until retired.

Proposal

I propose there is a way to declare an EOL for module streams in two possible formats:

  • A specific date
  • A specific Fedora release

I propose there is no package-level EOL — this gets defined implicitly by the fact the package is included in a module. This relates to the stream branch ownership epic where my proposal is, simply put: If you include a package in your module, you are responsible for keeping it maintained. Packages that are not in a module are not being built, so they don't really need an EOL declaration, because they don't exist from the user's perspective.

The system would work in a following way:

  • When you don't declare specific platform streams in modulemd and don't specify an EOL, the module is getting built in new releases forever.
  • When you do declare a specific platform streams in modulemd, the EOL computed from that definition.
  • When you declare a specific EOL, well, that's the EOL.
  • If there is a conflict between the platforms specified in modulemd and the explicit EOL definition, whatever comes earlier wins.

Two things to solve to make this proposal complete:

  • Where to put such EOL definition?
  • When the date format is used, do we:
    • Stop building the module for Fedora releases that reach their EOL before the module's EOL date?
      • That would require is knowing the Fedora release EOL.
      • What if the Fedora release suddenly slips after the module EOL?
    • Stop building the module for Fedora releases going GA after the module's EOL date.
      • That's not really a module's EOL date anymore, but
      • It's always clear when it gets built and when not, Fedora release slips don't matter.
    • Other options?

I don't have answers for those two things, and I would like to discuss them along this whole proposal with anyone interested.


Metadata Update from @asamalik:
- Issue tagged with: Meeting

a month ago

Metadata Update from @asamalik:
- Issue assigned to asamalik

a month ago

IMO EOL information can be where all SCM data is kept, in git.

I think that's generally reasonable, but:

  • We don't really have a place to store the EOL at the moment. It used to be PDC but...
  • Both GA and release EOL dates can slip

I think the easiest option would be just relying on the platform dependencies here but we'd like some input from other groups, such as FESCo and releng. I'll file a FESCo ticket for this.

we'll discuss this one with FESCo

Note we are building a PDC replacement called fpdc: https://fpdc.fedoraproject.org/ https://github.com/fedora-infra/fpdc It could well contain this info.

Login to comment on this ticket.

Metadata