Release Plan

Release plan bump type

When generating an Nx version plan in .nx/version-plans/, the bump type in the frontmatter MUST always be patch — never minor, never major — regardless of the nature of the change (new feature, new component, new prop, breaking change, refactor, fix, etc.).

---
'@ledgerhq/lumen-ui-rnative': patch
---

feat(Select): add render prop and SelectButtonTrigger

• Do not infer minor from feat(...) commits.
• Do not infer major from breaking changes.

One package per file

Each release plan file MUST list a single package in its frontmatter — never group multiple packages in the same file. If a change affects N packages, create N separate version-plan-<timestamp>-<pkg>.md files, one per package.

---
'@ledgerhq/lumen-ui-react': patch
---

feat(Select): add render prop and SelectButtonTrigger

---
'@ledgerhq/lumen-ui-rnative': patch
---

feat(Select): add render prop and SelectButtonTrigger

Do NOT do this:

---
'@ledgerhq/lumen-ui-react': patch
'@ledgerhq/lumen-ui-rnative': patch
---

Path → package

Each version-plan file names the package for the paths that changed. This is the single source for the mapping; other skills link here rather than restating it.

Filename convention: version-plan-<timestamp>-<pkg-slug>.md, where the slug is the short name (ui-react, ui-rnative, utils-shared, …).

When a plan is required

Any change to production source under libs/*/src/ requires a plan. Exemptions are defined authoritatively in nx.json under release.versionPlans.ignorePatternsForPlanCheck: *.test.* / *.spec.*, *.stories.*, *.md, *.mdx, *.figma.@(ts|tsx), tsconfig*.json, eslint configs, jest.config.*, test-setup.*, *.snap, .storybook/**. A PR touching only these needs no plan.