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"
            }

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.

## 关于版本 { #about-versions }

遵循语义版本控制约定，任何低于`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`。

///

%>[[release-notes-$unqualifiedVersion]]
== {es} version ${unqualifiedVersion}
<% if (version.isSnapshot()) { %>
coming[$unqualifiedVersion]
<% } %>
Also see <<breaking-changes-${ version.major }.${ version.minor },Breaking changes in ${ version.major }.${ version.minor }>>.
<% if (changelogsByVersionByTypeByArea[version]["security"] != null) { %>
[discrete]
[[security-updates-${unqualifiedVersion}]]
=== Security updates

        - 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?

        final Map<Boolean, Map<String, List<ChangelogEntry.Breaking>>> breakingChangesByNotabilityByArea = entries.stream()
            .map(ChangelogEntry::getBreaking)
            .filter(Objects::nonNull)
            .sorted(comparing(ChangelogEntry.Breaking::getTitle))
            .collect(
                groupingBy(
                    ChangelogEntry.Breaking::isNotable,

/**
 * 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 {

    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

coming::[{minor-version}]

Here are the highlights of what's new and improved in {es} {minor-version}!
ifeval::[\\{release-state}\\"!=\\"unreleased\\"]
For detailed information about this release, see the <<es-release-notes>> and
<<breaking-changes>>.
endif::[]
<% if (priorVersions.size() > 0) { %>
// Add previous release to the list
Other versions:

<%
print priorVersions.join("\n| ")
print "\n"
}

go1.txt (and similarly named files) are frozen once a version has been
shipped. Each file adds new lines but does not remove any.

except.txt lists features that may disappear without breaking true
compatibility.

Starting with go1.19.txt, each API feature line must end in "#nnnnn"
giving the GitHub issue number of the proposal issue that accepted
the new API. This helps with our end-of-cycle audit of new APIs.