"Method com.example.Source.baz(): From non-null returning to null-unmarked returning breaking change.",
            )
            assertHasNoWarning()
            assertHasNoInformation()
        }
    }

    @Test
    fun `from null-unmarked returning to non-null returning is not breaking`() {

        checkBinaryCompatibleJava(

                    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.

 *  Breaking: `RecordedRequest.body` is now nullable. Null is used when the request does not have a
    body.

 *  Breaking: `RecordedRequest.chunkSizes` is now nullable. Null is used when the request does not
    use chunked encoding. This is different from an empty list - that indicates the request is
    chunked but has no data.

## 关于版本 { #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`。

///

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 { #deployment-strategies }

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

Make sure you use a supported label from the [latest-changes list of labels](https://github.com/tiangolo/latest-changes#using-labels):

* `breaking`: Breaking Changes
    * Existing code will break if they update the version without changing their code. This rarely happens, so this label is not frequently used.
* `security`: Security Fixes

            return null
        }

        Optional<CtClass> oldClass = member.oldClass
        Optional<CtClass> newClass = member.newClass
        if (!oldClass.isPresent() || !newClass.isPresent()) {
            // breaking change would be reported
            return null
        }

        return checkSuperClassChanges(member, oldClass.get(), newClass.get())
    }

    protected abstract boolean changed(JApiCompatibility member)

  @Override
  protected void setUp() throws Exception {
    map = MutableClassToInstanceMap.create();
  }

  public void testConstraint() {
    /*
     * We'll give ourselves a pass on testing all the possible ways of breaking the constraint,
     * because we know that newClassMap() is implemented using ConstrainedMap which is itself
     * well-tested. A purist would object to this, but what can I say, we're dirty cheaters.
     */

- dict: словник
- enum: перелік
- issue: проблема
- server worker: серверний працівник
- worker: працівник
- software development kit: набір для розробки програмного забезпечення
- bearer token: токен носія
- breaking change: несумісна зміна
- bug: помилка
- button: кнопка
- callable: викликаємий
- code: код
- commit: фіксація
- context manager: менеджер контексту
- coroutine: співпрограма
- engine: рушій