# Deprecation notices

This page lists deprecations of Commodore features organized by version. We include a link to relevant documentation, if applicable.

## v1.8.0

### Parameter `-r / --repo-directory` for `component compile` is deprecated

We instead discover the component’s Git repository by recursively searching for a git repository in the component’s parent directories. When the parameter is provided, a deprecation notice is printed and the value of the parameter is discarded.

## v1.0.0

• Support for external postprocessing filter definitions is removed [deprecated in v0.16.0].

• Support for `parameters.component_versions` is removed [deprecated in v0.5.0].

• Deprecated inventory parameters `customer.name`, `cloud.provider`, `cloud.region` and `customer.name` are removed [deprecated in v0.3.0].

• Support for component specifications without explicit versions is removed [deprecated in v0.13.0]

• Support for advertising multi-instance support in component parameter `multi_instance` is removed [deprecated in v0.14.0].

• Support for component library names which aren’t prefixed with the component name is removed [deprecated in v0.16.0].

## v0.16.0

### External postprocessing filter definitions are deprecated

Commodore v0.4.0 introduced support for defining postprocessing filters in the component class. However, defining postprocessing filters in `postprocess/filters.yml` was never formally deprecated.

To migrate a component which still uses `postprocess/filters.yml`, you can simply move the contents of the file to parameter `commodore.postprocess`, remove the file and commit the changes.

``````component_name=component-name
export filters=$(yq e '.' postprocess/filters.yml) yq e -i '.parameters.commodore.postprocess = env(filters)' "class/${component_name}.yml"
rm -rf postprocess/
git commit -m "Move postprocessing filter definitions to component class"``````
 The provided snippet uses mikefarah/yq v4.

### Component library names which aren’t prefixed with the component name are deprecated

Commodore v0.16.0 adds support for explicitly specifying component library aliases. In turn, the previous approach of allowing components to provide libraries with arbitrary names is deprecated. Instead components should always prefix their component libraries with the component name. This introduces namespacing for component libraries by default.

The aliasing mechanism still allows multiple components which implement the same interface to expose their implementation of the shared interface under an arbitrary alias.

 Commodore will raise an error if multiple components in the hierarchy try to use the same component library alias.

## v0.14.0

### Advertising multi-instance support in component parameter `multi_instance` is deprecated

Commodore v0.14.0 adds support for advertising multi-instance support in components to field `multi_instance` in the component metadata parameter `_metadata`. In turn the old location for advertising multi-instance support in component parameter `multi_instance` is deprecated.

To update existing components, you can simply adjust the component’s `class/defaults.yml` to match the sample shown below.

``````parameters:
<component_name>: (1)
multi_instance: true``````
 1 `` is a placeholder for the component’s parameters key 2 By prefixing the `_metadata` key with an equals sign, we make the component metadata constant. This ensures that values in `_metadata` can’t be changed in the hierarchy. See also the Kapitan reclass documentation.
 Depending on the age of the component, the `metadata` key may already exist with empty content.

## v0.13.0

### `parameters.commodore.jsonnet_libs` is removed

The parameter has been deprecated since Commodore v0.6.0, and is removed in v0.13.0.

### Component specifications without explicit version are deprecated

Users should always specify an explicit `version` in component specifications. In general, we encourage users to switch to explicitly tagged versions for all components.

 To keep the previous default behavior, users can specify `version: master` in the component specification.

## v0.6.0

### `parameters.commodore.jsonnet_libs` is deprecated

Users should specify Jsonnet dependencies of components in the component’s `jsonnetfile.json`.

For now, Commodore itself ensures `kube-libsonnet` is available as `lib/kube.libsonnet`.

## v0.5.0

### `parameters.component_versions` is deprecated

Users should switch to `parameters.components` which has the exact same format.

## v0.4.0

• Class includes of components are removed. Instead components must be included with entries in the `applications` array.

## v0.3.0

• The reclass hierarchy must be configured in the global defaults repository. See the reference docs for details.

• The following parameters will be removed in a future release. They’re replaced by keys in `parameters.facts` and `parameters.cluster`:

• `parameters.cluster.dist``parameters.facts.distribution`

• `parameters.cloud.provider``parameters.facts.cloud`

• `parameters.cloud.region``parameters.facts.region`

• `parameters.customer.name``parameters.cluster.tenant`