## About the changes
Introducing a Guideline Document for creating new REST endpoints.
It's an ADR, but it doesn't cover everything this kind of document
should.
From here we can either iterate on it or change it's name to be more
specific. (Ideas?)
### Important files
## Discussion points
## OSS PR checklist
- [x] I have read and agree to the [Unleash Contributor License
Agreement](https://github.com/Unleash/unleash/blob/main/CLA.md).
- [x] I have added tests or explained why tests are not needed.
- [x] I have updated documentation where relevant.
---------
Co-authored-by: Gastón Fournier <gaston@getunleash.io>
Turn out that there is no one that thinks we should be using Styled
prefix by default. This PR removes the lint and adds a small notes so we
can reference it later.
## Summary
- Adds a `docker exec postgres createdb -U unleash_user unleash_test`
step to the first-time setup in `CONTRIBUTING.md`
- Placed immediately after the initial `docker run` so both `unleash`
and `unleash_test` databases are created before the developer runs `pnpm
dev` or `pnpm test`
Without this step, a developer following the setup guide and then
running `pnpm test` hits a cryptic `error: database "unleash_test" does
not exist` error with no pointer to the fix.
Closes#12253
## About the changes
This introduces a lightweight Contributor License Agreement process for
the OSS repository after the move to AGPL.
The goal is to make contribution rights explicit without adding
unnecessary friction for community contributors. Contributors keep
ownership of their work, while Unleash receives the permissions needed
to continue developing, distributing, and, when needed, relicensing
accepted contributions.
The process is intentionally simple: contributors acknowledge the
agreement as part of the pull request flow, and automated dependency
updates can continue through the existing bot workflow. This gives the
project a clearer long-term governance trail while keeping day-to-day
contributions familiar.
## Discussion points
- Legal should review the final CLA wording before the signing flow is
treated as authoritative.
- Maintainers will still need to configure the external CLA check and
branch protection after this lands.
- The policy avoids adding individual copyright headers to source files;
attribution remains based on the project history and review trail.
---------
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Things worth noticing (+14075, -20262 most of this is due to yarn.lock
being deleted, and a new package manager tool being checked in)
## Code changes (actual changes to ts files)
### Not interesting
- being explicit about test imports in frontend rather than using
tsconfig globals to resolve `describe`, `it`, `test`, `expect` et al.
### Interesting
- Type signatures resolutions have changed a slightly bit, so some of
our Knex queries needed to be extracted for tsc to manage to type
analyse and pass type checking. All tests are green, so I'm assuming I
managed to reproduce the behaviour, in particular
src/lib/features/project/project-read-model.ts has some extra variables
to pass typechecking.
### Other considerations
- Do we still build the way we did? (pnpm pack produces the same
files/artifact as yarn pack)
- Will this merge cleanly with enterprise (which runs prepack)?
#### Known unknowns
- I've changed our vite.config.mts in frontend to use vite's own built
in tsconfigpaths, but Thomas pointed out that he tried that already and
ran into some issue when enterprise used the dependency, so we'll need
to double check that it works, and be ready to rollback to using the
deprecated plugin (and accept that vite gives us a warning that this is
now native functionality).
### Build failures
- Expected is openapi validation on main, we've changed to using pnpm
action rather than yarn action so it won't recognize yarn as a
packageManager on main
- dependency scanner, due to how pnpm resolves dependencies, we now have
a more direct dependencies, which our scanner apparently is scoring too
low for it to be OK with them. These were already a dependency, just
transitively rather than direct, so I'm comfortable with this.
## Description
This PR resolves multiple inconsistencies in the documented and enforced
Node.js and PostgreSQL versions across the repository. Previously, a
contributor could find mentions of Node 18, 20, and 22 depending on
which file they read.
### The Problem
*
**[.node-version](cci:7://file:///home/13769K/Git/forks/unleash/.node-version:0:0-0:0)**
was set to **22.22**.
*
**[backend/overview.md](cci:7://file:///home/13769K/Git/forks/unleash/contributing/backend/overview.md:0:0-0:0)**
recommended **Node 22** and **PostgreSQL 14**.
*
**[CONTRIBUTING.md](cci:7://file:///home/13769K/Git/forks/unleash/contributing/CONTRIBUTING.md:0:0-0:0)**
had conflicting mentions of **Node 20** (L11) and **Node 18** (L39),
along with **PostgreSQL 13**.
* **Root
[package.json](cci:7://file:///home/13769K/Git/forks/unleash/package.json:0:0-0:0)**
only enforced **Node >=20**.
*
**[frontend/package.json](cci:7://file:///home/13769K/Git/forks/unleash/frontend/package.json:0:0-0:0)**
only enforced **Node >=18**.
### The Solution
To eliminate confusion, this PR standardizes all requirements on **Node
22.0+** and **PostgreSQL 14.0+**, aligning them with the current CI/CD
environment and the
[.node-version](cci:7://file:///home/13769K/Git/forks/unleash/.node-version:0:0-0:0)
file.
## Changes
-
**[CONTRIBUTING.md](cci:7://file:///home/13769K/Git/forks/unleash/contributing/CONTRIBUTING.md:0:0-0:0)**:
Updated general instructions to specify Node 22 and PostgreSQL 14.
-
**[package.json](cci:7://file:///home/13769K/Git/forks/unleash/package.json:0:0-0:0)
(Root)**: Bumped `engines.node` to `>=22`.
-
**[frontend/package.json](cci:7://file:///home/13769K/Git/forks/unleash/frontend/package.json:0:0-0:0)**:
Bumped `engines.node` to `>=22`.
## Verification Results
- [x] Verified
[.node-version](cci:7://file:///home/13769K/Git/forks/unleash/.node-version:0:0-0:0)
content matches the new documentation.
- [x] Verified backend guide already recommended Node 22.
- [x] Verified GitHub Action
[build.yaml](cci:7://file:///home/13769K/Git/forks/unleash/.github/workflows/build.yaml:0:0-0:0)
already uses Node 22.
## About the changes
This PR introduces automated API stability tracking using explicit
release milestones instead of a manual `beta: true` flag. Endpoints now
declare a release object (beta, stable, or both), and the current
Unleash version drives stability (alpha, beta, stable). This makes
stability self‑expiring and prevents endpoints from staying stuck in
beta because someone forgot to flip a boolean.
## Key benefits
- Self‑expiring milestones: version milestones automatically roll
endpoints forward; no manual cleanup
- More reliable than booleans: avoids “forgot to flip beta off” drift
- Explicit lifecycle: alpha/beta/stable windows are documented at the
endpoint definition **(open conversation about naming)**
- Selective disclosure: alpha endpoints are hidden from public docs but
remain functional for testing
Full details: See the ADR at
contributing/ADRs/back-end/api-version-tracking.md (link:
https://github.com/Unleash/unleash/blob/feat/opinionated-api-stability/contributing/ADRs/back-end/api-version-tracking.md)
## Developer guidance (assuming current version is 7.4.0)
- release is required for new endpoints, currently not enforced, but
once backfilled existing endpoints, it will be.
- release: `{ beta: 'x.y.z' }` → alpha until beta, then beta thereafter.
- release: `{ stable: 'x.y.z' }` → alpha until stable, then stable
thereafter.
- release: `{ beta: 'x.y.z', stable: 'a.b.c' }` → alpha → beta → stable
(beta must be before stable).
- release: `{ alpha: true }` → explicitly remain alpha.
**Examples:**
Assuming current is 7.4.0
- Beta today: `release: { beta: '7.1.0' }`.
- Beta now, stable later: `release: { beta: '7.3.0', stable: '7.6.0' }`.
- Alpha now, then stable: `release: { stable: '7.6.0' }`.
- Alpha now, then beta, then stable: `release: { beta: '7.6.0', stable:
'7.7.0' }`.
- Alpha until changed: `release: { alpha: true }`.
## Discussion points
- Removed beta flag: replaced by release milestones so stability
advances automatically over time.
- Legacy Unstable tag: should be removed and replaced with release
milestones plus an appropriate existing tag.
- We can later add a small deprecation mechanism (sunset date/version)
for a full lifecycle.
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Mateusz Prusaczyk
