///

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.

/// tip

The "MINOR" is the number in the middle, for example, in `0.2.3`, the MINOR version is `2`.

///

## Upgrading the FastAPI versions { #upgrading-the-fastapi-versions }

You should add tests for your app.

    fun atLeastVersion(
      major: Int,
      minor: Int = 0,
      patch: Int = 0,
    ): Boolean {
      val conscryptVersion = Conscrypt.version() ?: return false

      if (conscryptVersion.major() != major) {
        return conscryptVersion.major() > major
      }

      if (conscryptVersion.minor() != minor) {
        return conscryptVersion.minor() > minor
      }

/// 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`。

///

## 升级FastAPI版本 { #upgrading-the-fastapi-versions }

你应该为你的应用程序添加测试。

使用 **FastAPI** 编写测试非常简单（感谢 Starlette），请参考文档：[测试](../tutorial/testing.md)

### Minor changes to the library {#minor_library_changes}...

- **Security:**
Java serialization poses security risks, especially related to deserialization vulnerabilities.

- **Version Compatibility:**
With Java serialization, even minor changes to a class (like adding a field) can break compatibility.

- **Cross-Language Compatibility:**
Java serialization is inherently Java-centric and does not support cross-language scenarios well.

- **Type Safety:**

Public properties are **stable properties**: they CANNOT be renamed or removed without notice.
While we normally deprecate the feature or behavior itself, changes to the property cannot happen in a minor release.
Public properties must be documented.

**Internal properties** are not part of the Public API.
Internal properties are **unstable properties**: they CAN be renamed or removed without notice.

at any time that it is needed. During the release freeze, the bar for changes
in vendored packages is the same as it is for changes in non-vendored packages.
After a major release is out, minor Go releases follow a more involved process
documented at go.dev/wiki/MinorReleases#cherry-pick-cls-for-vendored-golangorgx-packages.

In addition to individual updates that happen on demand, all dependencies in

import common.Os
import configurations.FunctionalTest
import configurations.ParallelizationMethod
import java.io.File

/**
 * QuickCrossVersionTest only tests the last minor for each major version in the range.
 */
val QUICK_CROSS_VERSION_BUCKETS =
    listOf(
        listOf("0.0", "5.0"), // 0.0 <= version < 5.0
        listOf("5.0", "6.0"), // 5.0 <=version < 6.0

Pull requests
-------------

Unless the change is a trivial fix such as for a typo, it's generally best to
start by opening a new issue describing the bug or feature you're intending to
fix. Even if you think it's relatively minor, it's helpful to know what people
are working on. And as mentioned above, API changes should be discussed
thoroughly before moving to code.

Some examples of types of pull requests that are immediately helpful:

	}
}

func needApproval(filename string) bool {
	name := filepath.Base(filename)
	if name == "go1.txt" {
		return false
	}
	minor := strings.TrimSuffix(strings.TrimPrefix(name, "go1."), ".txt")
	n, err := strconv.Atoi(minor)
	if err != nil {
		log.Fatalf("unexpected api file: %v", name)
	}
	return n >= 19 // started tracking approvals in Go 1.19
}