Who am I?

• Pulp developer (really almost all areas)
• Based in NRW (Germany)
• Maintainer of pulp_ansible, pulp_gem, pulp-glue, pulp-cli and squeezer
• mdellweg in some places, x9c4 in others

Pulp has a lot of stakeholders.
They need:

• Installable stable products
• Service deployments

Installable, stable Products

We know how to do that:

• Release branches (y-stream)
• Release Tags (z-stream)
  • Packages

Don't talk about Pulp 4

Service Deployments

Neuland:

• Always the newest features
• Fast reaction time
  • 24x7

Deploy from source

Really?

Would you install Postgres from source?

What if we can make Pulp more like that?

A Library it is

Pulp has a bunch of features that are used by other projects and products.
It really is a library.
We just need to find a way to deliver bugfixes in no time.

Release whenever

• Make sure the main branch is always clean / ready to be released.
• No need to run any additional tests in the release process.
• Don't deliver changes in a way that merges need to happen in multiple repositories simultaneously.

New rules

• If, on a given Tuesday, there is a feature in main, we cut a new Y.
• If, on a given Tuesday, there is any bugfix in a release branch, we cut a new Z.
• Bugfixes being urgent, can be released as soon as backported.

Releasing must be easy

Triggering a new release should be down to the click of a button.

The whole process should only take a few minutes (so people actually stay to monitor it).

There's some work left to do.

Breaking Changes

Releases can happen every week.
Breaking changes not so much!

Deprecation Policy:
A breaking change can only happen in certain releases.
(current 3.40.0, next 3.55.0, probably +0.15.0 in the future)

Breaking Changes (2)

So plugins can add requirements like
"pulpcore>=3.40,<3.55".
We have these releases about twice a year.
Ideally we can deprecate plugin-api features a few releases before removing them.
Plugin CI shows triggered deprecation warnings loudly.

Thank You!

Q&A