# Major Release Branching

###### tags: `PulpCon 2020` `Branching` `Major release`

While Pulp 3 is a big improvement over Pulp 2, it is not perfect. Some of its imperfections will require backwards incompatible changes to the REST API. In this session we will discuss procedures that are needed to enable developers to work on these backwards incompatible changes in parallel with new features that will be delivered in Pulp 3.

Idea A:
* Bump the version on master branch to 4.0.0.dev and continue merging all features there.
* Cherry-pick backwards compatible features and bug fixes to the latest 3.y branch
* Create a new 3.y+1 branch after each 3.y release

Idea B:
* Create a 4.0 branch from master
* modifiction: "create 4.0 **when we decide that Pulp4 is now the released version**"
* Continue development of backwards compatible change on master branch
* Periodically merge master branch into 4.0
* Merge backwards incompatible changes into 4.0

## Notes

* How do we handle major release updates
* dnf example: has this problem, but trying to make it temporary
* multi-version master makes it *VERY* hard on the community
* "As soon as you **decide incompatible changes need to be implemented**, 'master' becomes next-version and current-supported-version becomes a support-branch"
* the easier it is to require submitters submit changes to previous-version, the harder it is to justify making the jump to The Next Major version
* how can we handle the maintenance issues (that we cannot avoid), while still being able to push for "just move to Pulp N+1" as the preferred way to move forward
* optimize to make moving-forward easy
* managing django-migration machinery makes everything...interesting
* master has migration 1, 2, 3, 4, I want to move 3 into pulp-3-release - now I can't **ever** migrate a pulp-3-release instance, tro pulp-4
* first migration to 4, would have to apply-all-3-migrations, then apply pulp-4 migrations that haven't already been applied?
* Knowing how to **develop** Pulp4, is a different discussion than how do we **release** pulp4
* maybe we can "start developing on Pulp4" right now? (master == 4, if there's an incompatible change coming we need to sanitize the Pulp-3 release situation/process first)
* **how can we align stakeholders on release process?**
* "The way you guys work on pulp, makes it hard for me (I just want to use Pulp) track what's going on. Versions are unstable, questionable whether it is ok to use in production."