@ferrflow/linux-arm64 7.7.2 → 7.8.1

package/README.md

@@ -305,6 +305,38 @@ format = "json"
 
 </details>
 
+#### One file per package
+
+A large monorepo does not have to keep every package in the root config. List the per-package files
+under `include`, and each project owns its own settings:
+
+```json
+{
+  "workspace": { "versioning": "semver" },
+  "include": ["services/*/ferrflow.json", "frontend/ferrflow.json"]
+}
+```
+
+```json
+{
+  "name": "api",
+  "changelog": "CHANGELOG.md",
+  "sharedPaths": ["../shared/"],
+  "versionedFiles": [{ "path": "Cargo.toml", "format": "toml" }]
+}
+```
+
+Paths inside an included file are relative to that file, and `path` defaults to its directory. The
+example above needs no `path`: `services/api/ferrflow.json` describes the package in
+`services/api`, and moving the directory does not require editing anything.
+
+Included files use the same keys as a `package` entry, so `dependsOn` still refers to packages by
+name and works across files. They may use a different format than the root config, and they can be
+mixed with an inline `package` array while you migrate.
+
+The following are rejected rather than silently ignored: an `include` pattern matching no file, two
+packages sharing a name, and an included file declaring `workspace`, `include`, or `package`.
+
 ## Versioning Strategies
 
 Each package can use its own versioning strategy. Set a default at the workspace level and override per package:
@@ -450,6 +482,23 @@ skip_ci = false  # force CI to run on release commits
 
 In `pr` mode, `skip_ci` defaults to `false` since the PR merge triggers CI naturally.
 
+### How `pr` mode releases
+
+`pr` mode runs in two phases, so nothing is published for a release that has not been accepted.
+
+The **proposing** run computes the bump, writes the version files and changelog onto the release
+branch, and opens or updates the pull request. No tags are created and no releases are published.
+Every later commit on the target branch regenerates the branch, so the open PR keeps tracking the
+version that would ship now.
+
+The **finalising** run happens after the PR merges. FerrFlow sees a `chore(release):` commit on the
+target branch whose versions carry no tag, and tags exactly those versions before publishing the
+releases. The versions are read from the version files, never recomputed, so merging a release PR
+cannot cascade into a further bump. Squash merges and merge commits both work.
+
+A package declared without `versionedFiles` has no version to read, so it is not finalised this way.
+Use `commit` mode for tag-only packages.
+
 ## Floating Tags
 
 Move abbreviated tags (e.g. `v1`, `v1.2`) to always point at the latest matching release:

package/package.json

@@ -12,5 +12,5 @@
     "type": "git",
     "url": "git+https://github.com/FerrLabs/FerrFlow.git"
   },
-  "version": "7.7.2"
+  "version": "7.8.1"
 }