|
| 1 | +# Versioning and stability |
| 2 | + |
| 3 | +Updatecli does not break your manifests on purpose. When something needs to change, the old |
| 4 | +syntax is deprecated and keeps working. It is never removed without a year of warning. |
| 5 | + |
| 6 | +## Semantic versioning |
| 7 | + |
| 8 | +Updatecli uses [SemVer-style](https://semver.org/) version numbers with an extended compatibility policy. Deprecated manifest syntax and CLI flags may be removed in minor releases after at least 12 months of notice. |
| 9 | + |
| 10 | +| Bump | Means | |
| 11 | +|---|---| |
| 12 | +| Minor | New plugins, new fields, new flags. May also drop a syntax that has been deprecated for over a year (see below). | |
| 13 | +| Patch | Bug fixes. | |
| 14 | +| Major | Reserved for a redesign of Updatecli itself. Routine deprecation removals do not need one. | |
| 15 | + |
| 16 | +Upgrading is safe as long as your manifests do not rely on syntax listed on the |
| 17 | +[deprecations page](https://www.updatecli.io/docs/help/deprecations/). |
| 18 | + |
| 19 | +## What is stable |
| 20 | + |
| 21 | +Two surfaces are covered by this promise: |
| 22 | + |
| 23 | +* **The manifest API**: top level keys, resource `kind` names, their spec fields, the meaning |
| 24 | + of their values, and the templating functions available in a manifest. |
| 25 | +* **The CLI**: command names, flag names and their behaviour, and `UPDATECLI_*` environment |
| 26 | + variables. |
| 27 | + |
| 28 | +The manifest API is the project's first priority. A manifest that works today is expected to |
| 29 | +keep working. |
| 30 | + |
| 31 | +## What is not stable |
| 32 | + |
| 33 | +* **The Go code** (`github.com/updatecli/updatecli/pkg/...`). It is public because Go offers no |
| 34 | + other way to structure a program, not because it is an API. Packages move and signatures |
| 35 | + change in any release. If you import Updatecli as a library, pin an exact version and expect |
| 36 | + work on every upgrade. |
| 37 | +* **Anything behind `--experimental`.** It may change or be withdrawn at any time. |
| 38 | +* **Log and report output.** It is written for people to read, not for scripts to parse. |
| 39 | + |
| 40 | +## Deprecation |
| 41 | + |
| 42 | +When a manifest key or a CLI flag is superseded: |
| 43 | + |
| 44 | +1. The old form keeps working and warns on every run, naming its replacement. |
| 45 | +2. It is listed on <https://www.updatecli.io/docs/help/deprecations/>. |
| 46 | +3. It stays supported for **at least 12 months** from that announcement. |
| 47 | + |
| 48 | +Once both conditions are met, meaning a year has passed and the deprecation is documented, the |
| 49 | +old form may be dropped in a regular release. A major version bump is not required for this, so |
| 50 | +the deprecation page is the page to watch. |
| 51 | + |
| 52 | +`updatecli manifest upgrade --save` rewrites most deprecated syntax for you. |
| 53 | + |
| 54 | +## Pinning |
| 55 | + |
| 56 | +A manifest can declare the minimum version it needs, which turns a confusing failure on an |
| 57 | +older binary into a clear one: |
| 58 | + |
| 59 | +```yaml |
| 60 | +name: Example |
| 61 | +version: '0.118.0' |
| 62 | +sources: |
| 63 | + #... |
| 64 | +targets: |
| 65 | + #... |
| 66 | +``` |
| 67 | + |
| 68 | +## Found a break? |
| 69 | + |
| 70 | +If an upgrade breaks a manifest that worked before, it is a bug, not an intentional change. |
| 71 | +Please open an issue with the manifest, both versions, and the output of each. |
0 commit comments