Skip to content

Commit

Permalink
fix Markdown rendering deprecation-policy.md (#1845)
Browse files Browse the repository at this point in the history
  • Loading branch information
tejal29 authored and balopat committed Mar 20, 2019
1 parent 25e7208 commit f80bf5d
Showing 1 changed file with 48 additions and 48 deletions.
96 changes: 48 additions & 48 deletions deprecation-policy.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,102 +2,102 @@

Skaffold adopts the [Kubernetes deprecation policy for admin facing components](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-a-flag-or-cli). In summary, deprecations to a flag or CLI command require the following notification periods, depending on the release track:

| Release Track | Deprecation Period |
| -------- | -------- |
| Release Track | Deprecation Period |
| -------- | -------- |
| Alpha (experimental) |0 releases |
| Beta (pre-release) | 3 months or 1 release (whichever is longer)|
| GA (generally available) | 6 months or 1 release (whichever is longer) |
| Beta (pre-release) | 3 months or 1 release (whichever is longer)|
| GA (generally available) | 6 months or 1 release (whichever is longer) |

**Breaking changes**
**Breaking changes**
A breaking change is when the primary functionality of a feature changes in a way that the user has to make changes to their workflows/configuration.
- **Breaking config change**: In case of Skaffold's pipeline config (skaffold.yaml) a breaking change between an old and new version occurs when the skaffold binary cannot parse the input yaml with auto-upgrade. This can happen when the new version removes a feature or when the new version introduces a mandatory field with no default value
- **Breaking functional change**: functional changes that force user workflow changes even when the config is the same or upgradeable.

## How do we deprecate things?
## How do we deprecate things?

A "deprecation event" would coincide with a release.
A "deprecation event" would coincide with a release.

1. we document the deprecation in the following places if applicable
a.) docs
b.) release notes
c.) command help
d.) logs
e.) https://skaffold.dev/docs/references/yaml/
f.) [deprecation policy](/deprecation-policy.md)
1. We document the deprecation in the following places if applicable
1. [Document](./docs) changes in relevant sections. These docs will be
published to [offical skaffold website](https://skaffold.dev/docs/)
2. Release notes
3. Command help
4. Log messages
5. https://skaffold.dev/docs/references/yaml/
6. [deprecation policy](/deprecation-policy.md)

2. if applicable, [from the kubernetes policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-a-flag-or-cli):
> Rule #6: Deprecated CLI elements must emit warnings (optionally disable) when used.
2. if applicable, [from the kubernetes policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-a-flag-or-cli):
> Rule #6: Deprecated CLI elements must emit warnings (optionally disable) when used.
# Current maturity of skaffold
# Current maturity of skaffold

## Skaffold.yaml (pipeline config)
The pipeline config, i.e. `skaffold.yaml` is **beta**.

The pipeline config, i.e. `skaffold.yaml` is **beta**.

This means that you can safely depend on the skaffold config with the assumption that skaffold will auto-upgrade to the latest version:

- Removal and non-upgradable changes are subject to the deprecation policy for all (even new) features under the config.
- Auto-upgradable changes are not considered breaking changes.
- Removal and non-upgradable changes are subject to the deprecation policy for all (even new) features under the config.
- Auto-upgradable changes are not considered breaking changes.

## Skaffold components

We are committed to design for auto-upgradeable changes in the config.
We are committed to design for auto-upgradeable changes in the config.
However the **behavior** of individual component might suffer breaking changes depending on maturity.

- Filewatcher: beta
- Builders
- local: beta
- googleCloudBuild: beta
- googleCloudBuild: beta
- kaniko: beta
- plugins gcb: alpha
- Artifact types:
- Artifact types:
- Dockerfile: beta
- Bazel: beta
- jibMaven: alpha
- jibGradle: alpha
- jibGradle: alpha
- Filesync: alpha
- Port-forwarding: alpha
- Taggers: beta
- Port-forwarding: alpha
- Taggers: beta
- gitCommit : beta
- sha256: beta
- dateTime : beta
- envTagger: beta
- Testers: alpha
- Structure tests: alpha
- Deployers: beta
- Helm: beta
- Helm: beta
- Kustomize: beta
- Kubectl: beta
- Kubectl: beta
- Profiles: beta

## Skaffold commands
## Skaffold commands

Commands and their flags are subject to the deprecation policy based on the following table list:

- build: beta
- completion: beta
- config: alpha
- delete: beta
- deploy: beta
- dev: beta
- diagnose: beta
- fix: beta
- help: beta
- init: alpha
- run: beta
- version: beta
- build: beta
- completion: beta
- config: alpha
- delete: beta
- deploy: beta
- dev: beta
- diagnose: beta
- fix: beta
- help: beta
- init: alpha
- run: beta
- version: beta


## Current deprecation notices
## Current deprecation notices


03/15/2019: With release v0.25.0 we mark for deprecation the `flags` field in kaniko (`KanikoArtifact.AdditionalFlags`) , instead Kaniko's additional flags will now be represented as unique fields under `kaniko` per artifact (`KanikoArtifact` type).
This flag will will be removed earliest 06/15/2019.
This flag will will be removed earliest 06/15/2019.

02/15/2019: With release v0.23.0 we mark for deprecation the following env variables in the `envTemplate` tagger:
- `DIGEST`
- `DIGEST_ALGO`
- `DIGEST_HEX`
Currently these variables resolve to `_DEPRECATED_<envvar>_`, and the new tagging mechanism adds a digest to the image name thus it shouldn't break existing configurations.
This backward compatibility behavior will be removed earliest 05/14/2019.
- `DIGEST_HEX`
Currently these variables resolve to `_DEPRECATED_<envvar>_`, and the new tagging mechanism adds a digest to the image name thus it shouldn't break existing configurations.
This backward compatibility behavior will be removed earliest 05/14/2019.

0 comments on commit f80bf5d

Please sign in to comment.