Jens/ModelForge-Public
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Publish curated ITWorx-ModelForge source from 990401737f96c8d46a9f7b0d84994516cadcb6a0

Browse Source
This commit is contained in:
Public Source Publisher committed 2026-09-30 09:23:17 +00:00
1 parent 7082ab955a
commit 848f0d8f8a
434 files changed
+67298 -4315
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

docs/COMPATIBILITY.md
+31 -22
View File
@@ -1,32 +1,31 @@
# Compatibility matrix — v1.2.1 plus unreleased RC hardening
# Compatibility matrix — v1.2.2 source/tag contract
Nothing here is implied. The executable contract lives in
`backend/src/modelforge_api/domain/release.py`; startup and release tests enforce it.
> RC development note: the unreleased product branch now targets additive schema
> `20260830_0024`, accepts `20260828_0022` and auth-only `20260830_0023` as upgrade sources, and refuses to serve until the
> audit-chain migration completes. Deployed stable v1.2.1 remains frozen on `20260828_0022`; the
> released matrix below continues to describe that production artifact until the RC is tagged.
> Selecting and stamping the post-0024 product version is an explicit pending release tranche; the
> temporary repository `1.2.1` constant must not be presented as a released schema-0024 artifact.
> Publication and deployment note: this file records the v1.2.2 source/tag compatibility contract.
> At the 2026-09-25 reconciliation checkpoint, Gitea's newest published Release object was v1.2.1;
> v1.2.2 existed as a tag. The observed production record was v1.2.3/schema-0032. The RC source
> is version 1.3.0-rc.1 with schema target 20260924_0039; it must not be treated as deployed until
> its own gates pass.
## Product and database
| Contract | Value |
| --- | --- |
| Version | `1.2.1` |
| Version | `1.2.2` |
| Channel | `stable` |
| Version source | repository `VERSION` |
| Runtime schema | `20260830_0023` |
| Direct upgrade-source schema | `20260827_0021`, `20260828_0022` |
| Runtime schema | `20260830_0024` |
| Direct upgrade-source schema | `20260827_0021`, `20260828_0022`, `20260830_0023` |
| Minimum direct upgrade | `v1.0.0` |
| PostgreSQL | 16+; Compose ships 17 |
| SQLite | unit tests only; **NOT SUPPORTED FOR PRODUCTION** |
The hardened candidate serves only on schema 0023. The upgrade tool accepts 0021 or the production
0022 head, applies the intervening revisions, validates all existing node credential scopes, and
reaches 0023 before the API starts. PostgreSQL is the only production database contract; SQLite is
used only to exercise DDL mechanics in isolated tests.
v1.2.2 serves only on schema 0024. The upgrade tool accepts 0021, the production 0022 head or the
intermediate auth-only 0023 head, applies the intervening revisions, validates existing node
credential scopes and establishes the PostgreSQL-owned audit boundary before the API starts.
PostgreSQL is the only production database contract; SQLite is used only for isolated tests.
Compatibility answers remain typed and fail closed:
@@ -45,19 +44,22 @@ Compatibility answers remain typed and fail closed:
| Accepted protocols | 1 |
The Node Agent and Runtime Worker remain protocol-compatible with v1.0.0. Release images should
still be upgraded together so their product and provenance identity is v1.2.1.
still be upgraded together so their product and provenance identity is v1.2.2. Because the Runtime
Worker dependency update is behavioral, existing profiles require fresh LAB evidence before
production promotion.
## Upgrade matrix
| From | Schema | To | Supported |
| --- | --- | --- | --- |
| `v1.0.0` | `20260827_0021` | current candidate / `20260830_0023` | yes; backup and rehearsal required |
| `v1.1.0` | `20260828_0022` | current candidate / `20260830_0023` | yes; scope validation migration |
| `v1.1.1` | `20260828_0022` | current candidate / `20260830_0023` | yes; scope validation migration |
| `v1.2.0` | `20260828_0022` | current candidate / `20260830_0023` | yes; scope validation migration |
| `v1.2.1` | `20260828_0022` | current candidate / `20260830_0023` | yes; scope validation migration |
| current candidate | `20260830_0023` | current candidate | yes; already current |
| older than `v1.0.0` | any | `v1.2.1` | no direct upgrade |
| `v1.0.0` | `20260827_0021` | `v1.2.2` / `20260830_0024` | yes; backup and rehearsal required |
| `v1.1.0` | `20260828_0022` | `v1.2.2` / `20260830_0024` | yes; scope and audit migration |
| `v1.1.1` | `20260828_0022` | `v1.2.2` / `20260830_0024` | yes; scope and audit migration |
| `v1.2.0` | `20260828_0022` | `v1.2.2` / `20260830_0024` | yes; scope and audit migration |
| `v1.2.1` | `20260828_0022` | `v1.2.2` / `20260830_0024` | yes; scope and audit migration |
| intermediate RC | `20260830_0023` | `v1.2.2` / `20260830_0024` | yes; audit-boundary migration |
| `v1.2.2` | `20260830_0024` | `v1.2.2` | yes; already current |
| older than `v1.0.0` | any | `v1.2.2` | no direct upgrade |
Because 0022 introduces terminal node and decommission-operation state, application-only rollback
to v1.0.0 is unsupported. Restore the verified pre-upgrade backup. Alembic downgrade may be used in
@@ -95,6 +97,13 @@ PATCH under SemVer.
The console image is the one artifact whose *behaviour* differs, because the previous images could
not reach a non-localhost API at all. That is a defect being repaired, not a capability being added.
## Why v1.2.2 is a PATCH release
v1.2.2 hardens public packaging, dependency and database-authority boundaries without changing the
capability API or agent protocol. The Runtime Worker dependency set changes and is therefore
classified `behavioral` operationally: it remains a patch release, but production promotion is
blocked until exact LAB probes prove compatibility, output shape and unload/reclaim behavior.
## Why v1.2.0 is a MINOR release
v1.2.0 adds substantive, backward-compatible product capability at the console layer: a command