---
# System prepended metadata

title: Balancing Act between Services and Products
tags: [PulpCon 2023]

---

---
title: Balancing Act between Services and Products
tags: PulpCon_2023
description: This talk will discuss Pulp''s Release Cadence and the Deprecation Policy from both a consumer as well as a developer viewpoint.
---

# 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