# Motivations
## When will we know the time is right? What will push us over the edge?
* We are building up technical debt (concerns or issues or solutions are put off because it would be a breaking change requiring a Pulp 4)
* Self fulfilling prophecy (making migration/upgrade more painful)

## What are the list of features that would require a new X Release? (just pick 1)

Thought experiment
- if we did a release a new X release, what are the things that would need to change to make this happen?
- Note: we aren't suggesting time based features, just force us to think about what things need to change in order to start putting out a roadmap where 1 thing can be picked as the Pulp 4 release

# Will we ship a v3 and v4 API at the same time?
*

# Pulp 2 issues
* Lots of variation within the systems in the wild

# Ideas for future discussions
* Whatever goes into Pulp4 how will it be painful for our integrators/stakeholders/developers?
* Let's gather the superset of ideas for breaking changes and then select what we can afford to deliver in Pulp4.

# Problems with 2-to-3 migration (What are we not going to do in Pulp 4)
* Took a long time to deliver
* Integrators had to put in huge effort to switch
* Developers having to split brian between the old and new version.
* The way you stood up the "old" version and the "new" version were totally different. Hard to maintain two environments.
* Too many changes (tech stack, dev environment)
* get management buy in first

* We had to adapt downstream user (Katello) workflows to a completely new workflow (multiple repositories -> one repository many repository versions, specifically). Doing so was a massive bear and made the migration so much worse.
* A more straightforwards tech stack transition for Pulp 3 without as radical architectural changes (repo versions) would maybe have been preferable - delivered faster and migrated to more quickly
*

# What are the challenges for a pulp 4

# How can we address those challenges?
* don't release so often
* don't have Pulp 4 be a separate application that has to stand up separately
* parallel APIs within the same application
* or at least shared workers / content app?
* do as much as we can in Pulp 3 to get close to the ideal, so that Pulp 3 is as small of a change as possible
* e.g. introducing new APIs

# Ideas
* We perhaps made some things a bit too flexible in Pulp 3 - e.g. syncing arbitrary remotes against arbitrary repos.
* Which then made our APIs more complicated by default for things that could and should be simple.
* https://github.com/pulp/pulpcore/issues/2010
* Keep

# Questions
Does Pulp4 mean package that are 4.y or is it a /v4/ REST API shipped in Pulp 3.y