Skip to content

Commit 2c15bfa

Browse files
authored
[chore][VERSIONING.md] Changing protocol support for security is allowed (#10460)
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description <!-- Issue number if applicable --> We have recently discussed bumping the minimum TLS version to follow security best practices. Since we are about to stabilize `configtls` (see #10344), I raised the question of whether this would be a breaking change that should be done before 1.0. I argue that we should be allowed to do this after 1.0 because: - The Go 1 version compatibility doc states > Security. A security issue in the specification or implementation may come to light whose resolution requires breaking compatibility. We reserve the right to address such security issues. - The Go team has made [similar changes](golang/go#45428) in the past for Go as a whole While this is not a security issue but a security best practice, the golang/go issue seems to indicate that changes like this would be in the spirit of the Go 1 version compatibility promise.
1 parent a082f2e commit 2c15bfa

File tree

1 file changed

+1
-0
lines changed

1 file changed

+1
-0
lines changed

VERSIONING.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -30,6 +30,7 @@ Unless otherwise specified in the documentation, the following may change in any
3030
change its output in any way.
3131
* **Go version compatibility**. Removing support for an unsupported Go version is not considered a breaking change.
3232
* **OS version compatibility**. Removing support for an unsupported OS version is not considered a breaking change. Upgrading or downgrading OS version support per the [platform support](docs/platform-support.md) document is not considered a breaking change.
33+
* **Protocol compatibility**. Changing the default minimum version of a supported protocol (e.g. TLS) or dropping support for protocols when there are security concerns is not considered a breaking change.
3334
* **Dependency updates**. Updating dependencies is not considered a breaking change except when their types are part of the
3435
public API or the update may change the behavior of applications in an incompatible way.
3536

0 commit comments

Comments
 (0)