# Fidesplus update: monorepo merge and new development workflow
TL;DR - Fides core now lives inside the fidesplus repository — one clone, one dependency tree, one CI pipeline.

## Monorepo merge (Fides + Fidesplus)
* Merged Fides OSS into fidesplus via the fides/pre-merge integration branch (PR #3645).
* Fides core code is now at src/fides/; Fidesplus remains at src/fidesplus/.
* Fides tests moved in-tree at tests/fides/ (alongside existing tests/fidesplus/).
* Fides docs, clients (Admin UI, Privacy Center), and related assets ship in the same repo — no separate ethyca/fides checkout for day-to-day work.
* Single root pyproject.toml + uv.lock replaces the old split packaging model.

## Tooling and developer experience
* uv is now the standard way to install dependencies (uv sync --all-groups) and run nox sessions.
* Ruff handles Python formatting and linting across the unified codebase.
* Pyrefly replaces mypy for static type checking (CI still exposes a legacy “mypy” job name until branch protection is updated).
* README and CONTRIBUTING were updated to describe the monorepo layout and local dev flow.

## CI and build pipeline updates
* GitHub Actions caches are scoped with a monorepo prefix to avoid cross-poisoning with pre-merge history.
* Classify tests now run on the host (Postgres + Redis) instead of inside Docker, with configurable DB endpoints.
* Static checks, backend test workflows, and Docker publish paths were adjusted for the combined tree.
* Changelog tooling was updated to handle fragments imported from the Fides merge; db-migration is now a supported changelog label.

## Post-merge stabilization on `dev`
Follow-up work on the new `dev` integration branch (currently ahead of merge-base main) includes:

* OAuth test async-loop fixes
* Version calculation and formatting cleanup after the pyproject merge
* Slim Docker image fixes
* Test harness updates (tmp_path instead of deprecated py._path.local)
* Committed uv.lock and adjusted .gitignore
* Minor CI quality-of-life (optional skip-pr-size-check label, Chromatic temporarily disabled, CodeQL upload gated when security features are off)

## What this means for you
* Clone fidesplus only — Fides and Fidesplus changes go in one PR.
* Target the dev branch for active development; main stays stable/release-oriented (see the git-flow workflow we’re adopting).
* Use uv run nox for builds, tests, and dev environments — same commands cover both packages.


## Git-flow workflow

(or, the "dev as unstable, main as _always_ stable" workflow)

It has been proposed that we try a new development workflow in an attempt to keep an "always stable" branch (main) that will always house code that has been released. Given that this merge means we can get started with this model easily. (We have not made a formal decision so for more info see [this Atlassian post](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) or [the original post](https://nvie.com/posts/a-successful-git-branching-model/)) or see below for the bullet-point overview (basic mental model is: `dev` is where day-to-day development happens and  `main` holds only stable, production-ready release history)

### Core branches 

| Branch	 | Purpose |
|-----|----|
|main|	Official release history. Always reflects the latest stable production code.|
|dev	|Integration branch for ongoing work. All active development targets this branch.|


### Supporting branches

|Branch pattern	| Branched from	 | Merged into |	When to use |
|---------------|----------------|-------------|----------------|
|feature/*	    | dev	         | dev	       | New features and non-release work. Open PRs against dev. |
 |release/*	| dev |	main and dev |	Preparing a production release: final testing, bug fixes, version/changelog updates. Does not block new feature work on dev. |
| hotfix/*	| main	| main and dev	 | Urgent production fixes. Because main is always the latest stable code, hotfixes branch from main and are backported to dev.|

### Releases

1. When a release is ready, create a release/* branch from dev.
2. Stabilize and test on the release branch (fixes and metadata only—no new features).
3. When the release ships, merge the release branch into main and dev.
4. Tag the merge commit on main (e.g. v2.x.x). That tag is the official release point.

### Day-to-day development
1. Clone the repo and base new work on dev (not main).
2. Create feature/* branches from dev, then open PRs back into dev. (or username/PR, whatever we want to settle on)
3. Treat main as effectively **read-only** for feature work—it moves only via releases and hotfixes.