# Balancing Act between Services and Products A talk about why Pulp releases so damn frequently. --- ## 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 <!-- .element: class="fragment" data-fragment-index="1" --> - Service deployments <!-- .element: class="fragment" data-fragment-index="2" --> --- ## Installable, stable Products We know how to do that: - Release branches (y-stream) <!-- .element: class="fragment" data-fragment-index="1" --> - Release Tags (z-stream) <!-- .element: class="fragment" data-fragment-index="2" --> - Packages <!-- .element: class="fragment" data-fragment-index="3" --> --- # :face_with_finger_covering_closed_lips: _Don't talk about Pulp 4_ --- ## Service Deployments Neuland: - Always the newest features <!-- .element: class="fragment" data-fragment-index="1" --> - Fast reaction time <!-- .element: class="fragment" data-fragment-index="2" --> - 24x7 <!-- .element: class="fragment" data-fragment-index="3" --> --- ## Deploy from source # :scream: <!-- .element: class="fragment" data-fragment-index="1" --> --- ## Really? Would you install Postgres from source? <!-- .element: class="fragment" data-fragment-index="1" --> What if we can make Pulp more like that? <!-- .element: class="fragment" data-fragment-index="2" --> --- ## 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. <!-- .element: class="fragment" data-fragment-index="1" --> The whole process should only take a few minutes (so people actually stay to monitor it). <!-- .element: class="fragment" data-fragment-index="2" --> There's some work left to do. <!-- .element: class="fragment" data-fragment-index="3" --> --- ## 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) <!-- .element: class="fragment" data-fragment-index="1" --> --- ## 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. --- ## :tangerine: Thank You! :tangerine: ## Q&A