docs: 0.24.0 — contractVersion, and the lineage a DMM publish strips

README.md

@@ -19,7 +19,7 @@ The site is organised the way a reader uses it (get started, tutorials, how-to g
 
 ## Current Versioning
 
-- Current CLI release documented here: `0.23.0`
+- Current CLI release documented here: `0.24.0`
 - Contract schema: `fluidVersion: 0.7.5` is the stable default; `0.7.6` is an opt-in preview
 
 Those are different on purpose. `fluid version` reports the installed CLI release, while `fluidVersion` inside a contract selects the contract schema version.

docs/.vuepress/cli-version.json

@@ -1,6 +1,6 @@
 {
-  "supportedCliVersion": "0.23.0",
-  "supportedCliInstallSpec": "data-product-forge==0.23.0",
+  "supportedCliVersion": "0.24.0",
+  "supportedCliInstallSpec": "data-product-forge==0.24.0",
   "supportedFluidContractVersion": "0.7.5",
   "quickstartScaffoldVersion": "0.7.5",
   "supportedSdkVersion": "0.10.0",

docs/cli/README.md

@@ -1,6 +1,6 @@
 # CLI Reference
 
-This section tracks the command surface of `forge-cli` `0.23.0`, the release `pip install data-product-forge` installs. `fluid --help` shows the promoted commands.
+This section tracks the command surface of `forge-cli` `0.24.0`, the release `pip install data-product-forge` installs. `fluid --help` shows the promoted commands.
 
 ::: tip Looking up *how to do something* (not *what a command does*)?
 The page you actually want is [**CLI by task →**](./tasks/) — narrative walkthroughs organized around things you might be trying to accomplish, like "deploy to a new cloud", "add quality rules", "debug a failed run", or "add agent governance". Each task page links to the relevant commands. **This** page is the command index, grouped by purpose — better for lookup, worse for onboarding.

docs/cli/contract-tests.md

@@ -87,7 +87,7 @@ The contract is loaded the way `fluid plan` loads it, with `$ref` fragments and
 ```yaml
 - name: Schema gate
   run: |
-    pip install data-product-forge==0.23.0
+    pip install data-product-forge==0.24.0
     fluid contract-tests contract.fluid.yaml --baseline baseline.schema.json
 ```
 

docs/cli/datamesh-manager.md

@@ -139,6 +139,8 @@ For ODPS publishes, product-to-product `consumes[]` entries are not kept as ODPS
 
 That default avoids duplicated lineage nodes: upstream data products stay data products, and are not mirrored as SourceSystem objects just to satisfy older ODPS importer behavior.
 
+Since 0.24.0 an ODPS export also derives `outputPorts[].inputContracts` from `consumes[]`, which states the same dependency a second time in one document. A stripped input port's lineage entry is removed with it, so the upstream is not left named in a payload that has no port to resolve it. Lineage a contract states for itself — an imported document's own `inputContracts`, replayed through the expose pass-through — is kept, because Access agreements are built from `consumes[]` and would not record it.
+
 Use `--odps-lineage-mode source-system` only for legacy DMM deployments that explicitly require SourceSystem custom properties on retained ODPS input ports. Explicit source-system consumes authored in the FLUID contract are still preserved as source-system input ports in the default `contract` mode.
 
 Access agreements are create-only by default. Use `--auto-approve-access`, `DMM_AUTO_APPROVE_ACCESS=true`, or catalog config `auto_approve_access: true` only when your environment intentionally auto-approves those agreements. `--no-auto-approve-access` forces pending agreements for one publish even when the environment variable is set.

docs/cli/mission.md

@@ -249,7 +249,7 @@ cosmetics ([`0.13.0` security fixes](../RELEASE_NOTES_0.13.0.md#security)).
 ```yaml
 - name: Mission gate
   run: |
-    pip install data-product-forge==0.23.0
+    pip install data-product-forge==0.24.0
     fluid mission check quality-coverage contract.fluid.yaml
 ```
 

docs/cli/scaffold-ci.md

@@ -41,7 +41,7 @@ The generated file installs `data-product-forge` from PyPI (`pip install --quiet
 | publish | On `main` with `DMM_API_URL` set: `fluid publish $CONTRACT --catalog $CATALOG`. |
 
 ::: warning Pin the version in a pipeline that holds credentials
-An unpinned `pip install data-product-forge` takes whatever release is latest when the job runs, and the same job holds the credentials the apply stage uses. After generating, edit the install line to pin the version you tested, for example `pip install --quiet "data-product-forge==0.23.0"`, and move the pin deliberately when you upgrade. [`fluid generate ci`](./generate.md#fluid-generate-ci) pins the install to the version that generated the file.
+An unpinned `pip install data-product-forge` takes whatever release is latest when the job runs, and the same job holds the credentials the apply stage uses. After generating, edit the install line to pin the version you tested, for example `pip install --quiet "data-product-forge==0.24.0"`, and move the pin deliberately when you upgrade. [`fluid generate ci`](./generate.md#fluid-generate-ci) pins the install to the version that generated the file.
 :::
 
 The settings are `CONTRACT` (the path you passed), `PROVIDER` (default `default`), `BUILD_ID` (default empty; set it to a `builds[].id` to run that build), `CATALOG` (default `datamesh-manager`), `AIRFLOW_DAGS_DEST` and `DMM_API_URL`. GitLab reads them as CI/CD variables, GitHub Actions as `env`, repository `vars` and `secrets`, Jenkins from the `environment` block.

docs/cli/version.md

@@ -69,7 +69,7 @@ Python: 3.11.15 (darwin)
 System: Darwin arm64
 ```
 
-`fluid --version` is the top-level flag and prints one line, `FLUID Forge CLI v0.23.0`.
+`fluid --version` is the top-level flag and prints one line, `FLUID Forge CLI v0.24.0`.
 
 ## Options
 

docs/faq/README.md

@@ -54,7 +54,7 @@ pip install --upgrade "data-product-forge[local]"
 fluid version
 ```
 
-Then follow the [upgrade guide](../upgrading.md). It has a checklist for each version you cross, because some upgrades need action: `0.17.0`, for example, moves remote state to a per-provider key for a contract that uses a per-contract state key, and needs one `fluid schedule-sync` to retire old Airflow DAGs if you sync Airflow DAGs, and `0.16.3` changed some results on purpose. Pin an exact version in CI (`data-product-forge==0.23.0`), not a range.
+Then follow the [upgrade guide](../upgrading.md). It has a checklist for each version you cross, because some upgrades need action: `0.17.0`, for example, moves remote state to a per-provider key for a contract that uses a per-contract state key, and needs one `fluid schedule-sync` to retire old Airflow DAGs if you sync Airflow DAGs, and `0.16.3` changed some results on purpose. Pin an exact version in CI (`data-product-forge==0.24.0`), not a range.
 
 Your contracts do not need a new `fluidVersion`: `0.18.1` reads `0.7.1` to `0.7.5`, and `0.7.6` as a preview.
 

docs/providers/README.md

@@ -8,7 +8,7 @@ Fluid Forge uses one contract format across local and provider-backed execution
 
 ## Docs baseline
 
-- CLI release covered by the primary docs: `0.23.0`
+- CLI release covered by the primary docs: `0.24.0`
 - Contract schema: `0.7.5` is the current stable version; `0.7.6` is a preview you opt into with `fluidVersion: "0.7.6"`. The GCP retention, encryption and `binding.principals` fields need `0.7.6`.
 - Which `fluidVersion` each scaffolding command writes is listed in [`fluid init`](../cli/init.md#which-fluidversion-each-path-writes).
 

docs/recipes/per-environment-overlays.md

@@ -250,7 +250,7 @@ jobs:
       matrix:
         env: [dev, staging, prod]
     steps:
-      - run: pip install "data-product-forge==0.23.0"
+      - run: pip install "data-product-forge==0.24.0"
       - run: fluid validate contract.fluid.yaml --env ${{ matrix.env }}
       - run: fluid plan     contract.fluid.yaml --env ${{ matrix.env }}
 ```

docs/reference/contract-0.7.5.md

@@ -9,7 +9,7 @@ description: "The fields of the FLUID 0.7.5 contract schema (stable): path, type
 
 Status: **stable**. Schema 0.7.5 is the newest stable schema bundled with the CLI. The newer 0.7.6 schema is a preview; see the [0.7.6 preview delta](./contract-0.7.6-preview.md).
 
-Generated from `fluid_build/schemas/fluid-schema-0.7.5.json` in the `data-product-forge` 0.23.0 package (sha256 `a1c33dc003599649`). It is the schema `fluid validate` checks a contract against, rendered without edits. To regenerate: `python scripts/gen_contract_reference.py`.
+Generated from `fluid_build/schemas/fluid-schema-0.7.5.json` in the `data-product-forge` 0.24.0 package (sha256 `a1c33dc003599649`). It is the schema `fluid validate` checks a contract against, rendered without edits. To regenerate: `python scripts/gen_contract_reference.py`.
 
 Each table row is one field, addressed by its path from the contract root: `.` descends into an object, `[]` marks the items of a list, and `<key>` stands for any key of a map. **Required** means required inside its parent object; the parent can itself be optional. **Allowed values** lists the enum, pattern and range the schema enforces. An object typed plainly `object` rejects keys the schema does not list; `object (open)` accepts extra keys and `object (free-form)` has no listed keys. A row that begins "Only when ..." exists only under that condition. See [how to read this reference](./README.md#how-to-read-a-row).
 

docs/reference/contract-0.7.6-preview.md

@@ -9,13 +9,13 @@ description: "What the FLUID 0.7.6 preview schema adds to, and changes in, the s
 
 Status: **preview**. A contract opts in with `fluidVersion: "0.7.6"`; a contract that declares 0.7.5 is unaffected. This page lists the difference between the 0.7.5 schema and the 0.7.6 schema as bundled with the CLI: added fields, fields whose definition changed, and fields removed. A field not listed here has the same type, required flag, allowed values, default and description in both; for those, use the [0.7.5 reference](./contract-0.7.5.md). A definition used at several paths is listed once, at its first path.
 
-Generated from `fluid_build/schemas/fluid-schema-0.7.6.json` in the `data-product-forge` 0.23.0 package (sha256 `9cef4fbdd5f562e0`). It is the schema `fluid validate` checks a contract against, rendered without edits. To regenerate: `python scripts/gen_contract_reference.py`.
+Generated from `fluid_build/schemas/fluid-schema-0.7.6.json` in the `data-product-forge` 0.24.0 package (sha256 `8c025e0466fcbe51`). It is the schema `fluid validate` checks a contract against, rendered without edits. To regenerate: `python scripts/gen_contract_reference.py`.
 
 Each table row is one field, addressed by its path from the contract root: `.` descends into an object, `[]` marks the items of a list, and `<key>` stands for any key of a map. **Required** means required inside its parent object; the parent can itself be optional. **Allowed values** lists the enum, pattern and range the schema enforces. An object typed plainly `object` rejects keys the schema does not list; `object (open)` accepts extra keys and `object (free-form)` has no listed keys. A row that begins "Only when ..." exists only under that condition. See [how to read this reference](./README.md#how-to-read-a-row).
 
 ## At a glance
 
-- Added: 93 rows
+- Added: 94 rows
 - Changed: 17 rows
 - Removed: 0 rows
 
@@ -101,6 +101,7 @@ Each table row is one field, addressed by its path from the contract root: `.` d
 | Path | Type | Required | Allowed values | Default | Description |
 | --- | --- | --- | --- | --- | --- |
 | `consumes[].contractId` | string | no |  |  | NEW in v0.7.6: The upstream contract's OWN id, for an upstream that has one of its own — a product not built with FLUID, registered in a catalog under an id FLUID did not derive. The canonical-port builder already prefers an explicit contractId over the derived `<productId>.<exposeId>`; until now `consumes[]` was closed, so there was no way to supply it and the derived id was exported as if the upstream answered to it. |
+| `consumes[].contractVersion` | string | no | matches `^(0\|[1-9]\d*)\.(0\|[1-9]\d*)\.(0\|[1-9]\d*)(?:-[0-9A-Za-z.-]+)?(?:\+[0-9A-Za-z.-]+)?$` |  | NEW in v0.7.6: The exact upstream contract version this product was built and tested against, within `versionConstraint`. Exported as the ODPS `inputPorts[].version`, and as the version of the matching `outputPorts[].inputContracts[]` entry. Without it the export derives the range's lower bound; for a range it cannot read it falls back to 1.0.0, because ODPS v1.0.0 requires a version on every input port and the field cannot simply be omitted. `versionConstraint` stays the range this product accepts; this is the single version its exported lineage claims. `fluid validate` does not check that it falls inside `versionConstraint`. |
 | `consumes[].upstreamWorkspace` | string | no | min length 1 |  | Cross-mesh only. Id of the federated workspace that owns this upstream, as declared in federation/upstreams.yaml. Set it when the upstream lives in another mesh rather than this workspace; omit it for a local upstream, which is resolved by walking the workspace. |
 | `consumes[].upstreamDigest` | string | no | matches `^sha256:[0-9a-f]{64}$` |  | Cross-mesh only. The contract digest this product was composed against, as sha256:&lt;64 hex&gt;. `fluid apply` re-fetches the upstream's live digest and compares: a mismatch means the upstream changed since composition. Required whenever upstreamWorkspace is set. |
 

docs/reference/preview-fields.md

@@ -89,6 +89,7 @@ unexpected)
 | `exposes[].contract.id` | 0.23.0 | An explicit, stable contract id for one output port, used verbatim as the ODCS `id` and the ODPS output port `contractId`. Without it the id is derived from the product and expose names, so renaming either changes it. See [pinning a contract id](#pinning-a-contract-id). |
 | `exposes[].binding.location.host` | 0.23.0 | Host or endpoint; for a Kafka binding, the bootstrap servers. The ODCS server mapper already read `host` and fell back to `account`, while the schema accepted only `account`, so the only valid way to set brokers was a field named for something else. Usually set per environment in an overlay, since the brokers differ by environment and the rest of the binding does not. |
 | `exposes[].binding.serialization` | 0.23.0 | `{value, key}`, each one of `json`, `avro`, `protobuf`, `xml`, `avro-confluent`, `json-confluent`. The only thing that moves a Kafka server's exported ODCS `format` off `kafka_topic`. See [declaring the wire format](#declaring-the-wire-format). |
+| `consumes[].contractVersion` | 0.24.0 | The exact upstream version this product was built and tested against, inside `versionConstraint`. An ODPS input port's `version` used to be the `1.0.0` default whenever the contract stated only a range, asserting a pin the contract never made; the export now resolves the range's lowest accepted version, and this field overrides it when you know the one you tested. |
 | `exposes[].contract.schema[].quality` | 0.23.0 | Column-level data quality rules, in ODCS's own shape, written straight into `schema[].properties[].quality[]` of the exported contract. Setting it replaces the rules forge derives for that column. See [column quality rules](#column-quality-rules). |
 
 The [0.7.6 preview delta](./contract-0.7.6-preview.md) holds the full row for every field above, grouped by the top-level key it hangs off (`metadata`, `exposes`, `description`, `consumes`, `builds`) and in the order the schema declares them.

docs/sdk-and-plugins/journeys/custom-validator.md

@@ -459,7 +459,7 @@ Three places this typically gets installed:
    ```
 3. **CI** — the bundle from [your-own-ci](./your-own-ci.md) already has a `validate` stage. Add `my-org-validators` to the `pip install` line:
    ```yaml
-   - run: pip install --index-url "<your-private-index-url>" "data-product-forge==0.23.0" "my-org-validators==<version>"
+   - run: pip install --index-url "<your-private-index-url>" "data-product-forge==0.24.0" "my-org-validators==<version>"
    - run: fluid validate contract.fluid.yaml --strict
      env:
        FLUID_PLUGINS_ALLOWLIST: "steward-required,cost-center-required,classification-from-vocab,local"

docs/sdk-and-plugins/journeys/your-own-scaffolding.md

@@ -176,7 +176,7 @@ keywords = [
 
 dependencies = [
     "pydantic>=2.0",
-    "data-product-forge==0.23.0",
+    "data-product-forge==0.24.0",
 ]
 
 [project.optional-dependencies]

docs/sdk-and-plugins/reference/companion-packages.md

@@ -48,7 +48,7 @@ The PyPI name reflects the product brand (`data-product-forge`). The import path
 
 ```toml
 dependencies = [
-    "data-product-forge==0.23.0",  # pin exact for reproducibility
+    "data-product-forge==0.24.0",  # pin exact for reproducibility
 ]
 ```
 

docs/sdk-and-plugins/reference/trust-model.md

@@ -167,7 +167,7 @@ Plugins are tested, scanned, and approved by your platform team before showing u
 
 ```toml
 # In your deploy environment's pyproject.toml or requirements:
-data-product-forge==0.23.0
+data-product-forge==0.24.0
 data-product-forge-sdk==0.10.0
 data-product-forge-custom-scaffold==0.4.1
 my-org-validators==1.2.0

docs/vision.md

@@ -147,7 +147,7 @@ fluid market --search "customer analytics"
 
 ## Versioning in the docs
 
-- Current CLI release baseline: `0.23.0`
+- Current CLI release baseline: `0.24.0`
 - Current scaffolded contract examples: `fluidVersion: 0.7.5`
 
 That split is intentional. The CLI release and the contract schema version move on related but different timelines.