|
| 1 | +# HOWTO: Deprecate a package or individual feature |
| 2 | + |
| 3 | +## Introduction |
| 4 | + |
| 5 | +You can mark a package or an individual feature as `deprecated`. Deprecation means that the package or feature is retired and will only be maintained for a defined period. packages maintained by Elastic the maintenance period will follow EOL policies that can be found in [https://www.elastic.co/support/eol](https://www.elastic.co/support/eol). |
| 6 | + |
| 7 | +Individual feature deprecation is supported for: inputs, policy templates, variables, and data streams. |
| 8 | + |
| 9 | +Deprecation markers are available since spec version `3.6.0`. |
| 10 | + |
| 11 | +## Lifecycle of package or feature deprecation |
| 12 | + |
| 13 | +1. A package or feature is marked as deprecated. |
| 14 | + You set the `deprecated.since` field to the version when deprecation takes effect and the `deprecated.description` field with a message regarding the deprecation. Both are required. Optionally, you can add information about a new package or feature that replaces the current one using `deprecated.replaced_by`. Available fields for replacing a package or individual feature are: `package`, `input`, `policy_template`, `variable` and `data_stream`. |
| 15 | + |
| 16 | + Some examples of deprecated field: |
| 17 | + |
| 18 | + ```yaml |
| 19 | + # deprecated package |
| 20 | + deprecated: |
| 21 | + since: "2.4.0" |
| 22 | + description: This package is deprecated and will reach End-of-Life after the maintenance period. |
| 23 | + replaced_by: |
| 24 | + package: new_integration |
| 25 | + ``` |
| 26 | +
|
| 27 | + ```yaml |
| 28 | + # deprecated policy_template |
| 29 | + deprecated: |
| 30 | + since: "2.4.0" |
| 31 | + description: This policy_template is deprecated. |
| 32 | + replaced_by: |
| 33 | + policy_template: new_policy |
| 34 | + ``` |
| 35 | +
|
| 36 | + ```yaml |
| 37 | + # deprecated input |
| 38 | + deprecated: |
| 39 | + since: "2.4.0" |
| 40 | + description: This input is deprecated. |
| 41 | + replaced_by: |
| 42 | + input: new_input_name |
| 43 | + ``` |
| 44 | +
|
| 45 | +2. It remains available in the registry for installation and use. |
| 46 | +
|
| 47 | +3. A maintenance period follows (usually one year), during which the package or feature stays available and can receive critical fixes. Newer versions of the package can be released, which should update the deprecated information. |
| 48 | +
|
| 49 | +4. After this period, the package or feature reaches End-of-Life (EOL) and may be removed from the registry if the authors choose to do so. |
| 50 | +
|
| 51 | +## Deprecate a package |
| 52 | +
|
| 53 | +1. Bump the package version and set the deprecation in the package manifest (`manifest.yml`). Add a `deprecated` block with `since` set to the current package version: |
| 54 | + |
| 55 | + ```yaml |
| 56 | + format_version: "3.5.0" |
| 57 | + name: my_integration |
| 58 | + title: My Integration |
| 59 | + version: "2.4.0" |
| 60 | + # ... other manifest fields ... |
| 61 | +
|
| 62 | + deprecated: |
| 63 | + since: "2.4.0" |
| 64 | + description: This package is deprecated and will reach End-of-Life after the maintenance period. |
| 65 | + ``` |
| 66 | + |
| 67 | +2. Document the deprecation in the changelog (`changelog.yml`). Add an entry for this version and use the `deprecation` type so that Fleet UI can show deprecation warnings: |
| 68 | + |
| 69 | + ```yaml |
| 70 | + # newer versions go on top |
| 71 | + - version: "2.4.0" |
| 72 | + changes: |
| 73 | + - description: This package is deprecated and will reach End-of-Life after the maintenance period. |
| 74 | + type: deprecation |
| 75 | + link: https://github.com/elastic/integrations/issues/1234 |
| 76 | + ``` |
| 77 | + |
| 78 | +3. Publish the new version to the package registry. From this version onward, the package is officially retired but remains installable; Kibana will display warnings during the maintenance period. |
| 79 | + |
| 80 | +## Deprecate an individual feature |
| 81 | + |
| 82 | +1. Add deprecation to the feature in the appropriate manifest. For a data stream, set the `deprecated` block in that data stream’s `manifest.yml`. The exact schema is defined in the Package Spec; typically it includes `since` with the version when the feature was deprecated. |
| 83 | + |
| 84 | + Example of a data stream manifest (`data_stream/<stream_name>/manifest.yml`): |
| 85 | + |
| 86 | + ```yaml |
| 87 | + title: "Legacy logs" |
| 88 | + type: logs |
| 89 | + # ... other data stream fields ... |
| 90 | +
|
| 91 | + deprecated: |
| 92 | + since: "2.4.0" |
| 93 | + ``` |
| 94 | + |
| 95 | +2. Record the change in the changelog (`changelog.yml`) with type `deprecation`: |
| 96 | + |
| 97 | + ```yaml |
| 98 | + - version: "2.4.0" |
| 99 | + changes: |
| 100 | + - description: The "legacy_logs" data stream is deprecated and will be removed in a future version. |
| 101 | + type: deprecation |
| 102 | + link: https://github.com/elastic/integrations/issues/1234 |
| 103 | + ``` |
| 104 | + |
| 105 | +3. Publish the new package version. The deprecated feature stays available for the maintenance period; Kibana and Fleet can show warnings based on the registry and changelog. |
| 106 | + |
| 107 | +## Updates to a deprecated package |
| 108 | + |
| 109 | +Modifications to a deprecated package are allowed as long as the deprecated status is kept. You can release security updates or other patches: bump the version (for example from 2.4.0 to 2.4.1), keep the `deprecated` block in the manifest, and update the deprecation description if needed. The package remains deprecated; only the version and the message change. |
| 110 | + |
| 111 | +The package registry always exposes the latest deprecation information for a package. If a package was deprecated in 2.4.0 and you later release a patched version 2.4.1 that is also deprecated (with or without an updated description), clients that retrieve package information via the registry will see the deprecation details from 2.4.1 — the most recent version — not from 2.4.0. |
0 commit comments