Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add breaking change policy to website #6049

Draft
wants to merge 5 commits into
base: main
Choose a base branch
from
Draft
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Next Next commit
Add breaking change policy to website
  • Loading branch information
timotheeguerin committed Feb 18, 2025
commit 66b21fc1674b6d97830e00afaf4d47a5e508abd6
1 change: 1 addition & 0 deletions website/src/content/current-sidebar.ts
Original file line number Diff line number Diff line change
@@ -53,6 +53,7 @@ const sidebar: SidebarItem[] = [
"handbook/style-guide",
"handbook/formatter",
"handbook/reproducibility",
"handbook/breaking-change-policy",
{
label: "Configuration",
items: ["handbook/configuration/configuration", "handbook/configuration/tracing"],
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add the stdout of the compiler is not a contract, use teh api for programmatic usage

Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@
---
title: Breaking Change Policy
---

# Breaking Change Policy

import { Badge } from "@astrojs/starlight/components";

:::note
This is to be applicable after 1.0.0 release
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This is to be applicable after 1.0.0 release
The information in this document is applicable to TypeSpec packages with version 1.0.0 or greater.

:::

## Versioning Scheme

TypeSpec Compiler and libraries follow [semver](https://semver.org/) for versioning. Which means a breaking change(according the following policy) will only be introduced in a major version release.

## Breaking Change Philosophy

The basic of the policy can be summarized as follows, we guarantee stability for runtime behavior but not for the build process.

- A spec that was building successfully should build successfully with the new version of the compiler and libraries with the same major version.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- A spec that was building successfully should build successfully with the new version of the compiler and libraries with the same major version.
- A spec that builds successfully with a version of the TypeSpec compiler and its libraries will build successfully with a newer version of the compiler and libraries within the same major version.

- New types and functionalities can be added in a minor version release.
- If a spec updates to use that new functionality/type it is not considered a breaking change if it goes through a library/emitter that will now break.
- TypeScript types might change in ways that introcue compilation type checking errors. Those are not considered breaking changes.

### Bugs

A bug fix that requires breaking will not be considered a breaking change if the behavior was already broken to start with.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
A bug fix that requires breaking will not be considered a breaking change if the behavior was already broken to start with.
A bug fix that introduces a technically breaking change will not be considered a breaking change for the purposes of TypeSpec versioning if it is clear that the existing behavior was broken or unintended in the first place.


## Categories of Breaking Changes

- <Badge text="Level 0" variant="danger" />: Those Apis shouldn't be broken unless we make a major
version and a lot of consideration should given in making any of those. This should be apis that
are recommended to be used by library author.
- <Badge text="Level 1" variant="note" />: Those describe change that are not semantically relevant
but still produce noticeable changes in the output. This could be for example a change in the way
the output is formatted.
- <Badge text="Level 2" variant="tip" />: Those are internal apis that could be accessed but
touching it would be at the library author risk and breaking change wouldn't even need to be
documented
Comment on lines +34 to +42
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- <Badge text="Level 0" variant="danger" />: Those Apis shouldn't be broken unless we make a major
version and a lot of consideration should given in making any of those. This should be apis that
are recommended to be used by library author.
- <Badge text="Level 1" variant="note" />: Those describe change that are not semantically relevant
but still produce noticeable changes in the output. This could be for example a change in the way
the output is formatted.
- <Badge text="Level 2" variant="tip" />: Those are internal apis that could be accessed but
touching it would be at the library author risk and breaking change wouldn't even need to be
documented
- <Badge text="Level 0" variant="danger" />: These are stable core APIs and language features that define fundamental semantics and will not be broken without a major version update. We recommend that library authors depend on these APIs.
- <Badge text="Level 1" variant="note" />: These are APIs and language features that don't describe semantically meaningful information, but provide information that emitters and libraries may choose to use and may introduce changes in emitter output when the features are changed. For example: formatting.
- <Badge text="Level 2" variant="tip" />: These are internal APIs intended only for use by the TypeSpec compiler and core libraries. Level 2 APIs may be changed without a a major version update or even documentation of the change. Consuming these APIs is _at your own risk_!


| Example | Level | Description |
| -------------------------------- | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| TypeKit | <Badge text="0" variant="danger" /> | TypeKit will be moving forward the recommend way to expose apis for a library. Those should be extremely stable. |
| Additional helpers for a library | <Badge text="0" variant="danger" /> | Depending on the helper this could be considered critical or more advanced usage |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
| Additional helpers for a library | <Badge text="0" variant="danger" /> | Depending on the helper this could be considered critical or more advanced usage |
| Additional library helper functions | <Badge text="0" variant="danger" /> | Helper and metadata accessor functions exported from the public surface of the compiler or a TypeSpec library are generally considered stable unless otherwise specified or only exported through an experimental subpath. |

| TypeSpec SyntaxTree | <Badge text="2" variant="tip" /> | The TypeSpec Ast is not part of the contract a library should depend on. |
| Checker | <Badge text="2" variant="tip" /> | Checker is an internal of the typespec program |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
| Checker | <Badge text="2" variant="tip" /> | Checker is an internal of the typespec program |
| Checker | <Badge text="2" variant="tip" /> | Direct use of the Program's type checker instance is considered for internal use only and its API may change at any time. |

| Symbols | <Badge text="2" variant="tip" /> | Internals |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
| Symbols | <Badge text="2" variant="tip" /> | Internals |
| Symbols | <Badge text="2" variant="tip" /> | TypeSpec node symbols (not JavaScript symbols or state keys, rather the internal symbols used to relate TypeSpec types in the parser and type checker) are for internal use only. |

| Formatter | <Badge text="1" variant="note" /> | Formatting shouldn't' affect the meaning of the language. Changes to the formatting should be taken with consideration as it could create a lot of diff but it shouldn't also be considered a breaking change |
| Bug | [See bug](#bugs) | I think if something is found to be a bug from the documented behavior and fixing it is in someway breaking it shouldn't be considered as such unless it is such a widely used item where it has to become a "feature". Those should however still be documented as breaking in the release notes |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
| Bug | [See bug](#bugs) | I think if something is found to be a bug from the documented behavior and fixing it is in someway breaking it shouldn't be considered as such unless it is such a widely used item where it has to become a "feature". Those should however still be documented as breaking in the release notes |
| Bug fixes | [See bug](#bugs) | Bug fixes will not be considered breaking changes for the purposes of TypeSpec versioning if the existing behavior is _clearly_ broken or unintentional (e.g. if it violates the documented and expected behavior, or if there is no reasonable interpretation of the buggy behavior), even if the change is technically a breaking change. Bug fixes that are technically breaking will be documented as breaking changes in the release notes, but will not introduce a major version revision. However, if a bug's behavior has become so widely used as to be considered a "feature," we will consider the impact of the bugfix and make a reasonable determination to the best of our abilities and depending on the non-breaking mitigation strategies we have at our disposal. We will not break behaviors in stable releases that are known to be widely depended upon, even if we believe they are the result of a bug. |


### Supported node version

TypeSpec support all currently supported node version by the node foundation.
Loading
Oops, something went wrong.