By creating this pull request I represent that I have the right to license the 
contributions to the project maintainers under the Apache 2 license.

## Description


## Motivation and Context


## How to test this PR?


## Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)

FastAPI also follows the convention that any "PATCH" version change is for bug fixes and non-breaking changes.

/// tip

The "PATCH" is the last number, for example, in `0.2.3`, the PATCH version is `3`.

///

So, you should be able to pin to a version like:

```txt
fastapi>=0.45.0,<0.46.0
```

Breaking changes and new features are added in "MINOR" versions.

FastAPI también sigue la convención de que cualquier cambio hecho en una <abbr title="versiones de parche">"PATCH" version</abbr> es para solucionar errores y <abbr title="cambios que no rompan funcionalidades o compatibilidad">*non-breaking changes*</abbr>.

/// tip | Consejo

                    errors << "From non-nullable to nullable breaking change"
                } else if (oldNullability && !newNullability) {
                    warnings << "Nullability changed from nullable to non-nullable"
                }
            } else if (oldNullability != newNullability) {
                errors << "Nullability breaking change"
            }

        } else if (member instanceof JApiConstructor) {

## 关于版本

遵循语义版本控制约定，任何低于`1.0.0`的版本都可能会添加 breaking changes。

FastAPI 还遵循这样的约定：任何`PATCH`版本更改都是为了bug修复和non-breaking changes。

/// tip

"PATCH"是最后一个数字，例如，在`0.2.3`中，PATCH版本是`3`。

///

因此，你应该能够固定到如下版本：

```txt
fastapi>=0.45.0,<0.46.0
```

"MINOR"版本中会添加breaking changes和新功能。

/// tip

"MINOR"是中间的数字，例如，在`0.2.3`中，MINOR版本是`2`。

///

        - label: "Has this idea, or one like it, been proposed before?"
        - label: "Does this affect error handling?"
        - label: "Is this about generics?"
        - label: "Is this change backward compatible? Breaking the Go 1 compatibility guarantee is a large cost and requires a large benefit"

  - type: textarea
    id: related-proposals
    attributes:
      label: Has this idea, or one like it, been proposed before?

    needs:
      - labeler
    permissions:
      pull-requests: read
    runs-on: ubuntu-latest
    steps:
      - uses: docker://agilepathway/pull-request-label-checker:latest
        with:
          one_of: breaking,security,feature,bug,refactor,upgrade,docs,lang-all,internal

  /* For right to left languages */
  direction: ltr;
  display: inline-block;
}

a.external-link::after {
  /* \00A0 is a non-breaking space
        to make the mark be on the same line as the link
    */
  content: "\00A0[↪]";
}

a.internal-link::after {
  /* \00A0 is a non-breaking space
        to make the mark be on the same line as the link
    */
  content: "\00A0↪";
}

.shadow {

/**
 * Workaround for <a href="https://github.com/melix/japicmp-gradle-plugin/issues/56">japicmp issue w.r.t. superclass breakage</a>.
 *
 * <p>
 * Reports simple superclass changes (e.g. the removal of a superclass) as a breaking change, as it affects what methods can be
 * called with the given type, even if the methods and fields inherited don't change.
 * </p>
 */
class BinaryBreakingSuperclassChangeRule extends AbstractSuperClassChangesRule {

This is in contrast to the **development** stages, where you are constantly changing the code, breaking it and fixing it, stopping and restarting the development server, etc.

## Deployment Strategies

There are several ways to do it depending on your specific use case and the tools that you use.