Release 0.26.0 (openapi-generators#1306)

> [!IMPORTANT]
> Merging this pull request will create this release

## Breaking Changes

### Change some union variant names

When creating a union with `oneOf`, `anyOf`, or a list of `type`, the
name of each variant used to be `type_{index}`
where the index is based on the order of the types in the union.

This made some modules difficult to understand, what is a
`my_type_type_0` after all?
It also meant that reordering union members, while not a breaking change
to the API, _would_ be a breaking change
for generated clients.

Now, if an individual variant has a `title` attribute, that `title` will
be used in the name instead.
This is only an enhancement for documents which use `title` in union
variants, and only a breaking change for
_inline models_ (not `#/components/schemas` which should already have
used more descriptive names).

Thanks @wallagib for PR openapi-generators#962!

## Features

### Support patterned and default HTTP statuses

HTTP statuses like `2XX` and `default` are now supported!

A big thank you to:
- @PSU3D0 for PR openapi-generators#973 (eons ago 😅)
- @obs-gh-peterkolloch for PR openapi-generators#1300
- @goodsonjr for PR openapi-generators#1304

Closes openapi-generators#1271 and openapi-generators#832

> [!NOTE]
> Custom template users: the `endpoint.responses` type has changed quite
a bit. Check out openapi-generators#1303 for the changes.

Co-authored-by: knope-bot[bot] <152252888+knope-bot[bot]@users.noreply.github.com>

Release 0.25.3 (openapi-generators#1288)

> [!IMPORTANT]
> Merging this pull request will create this release

## Features

- Add --meta uv for generating astral-sh/uv compatible packages. (openapi-generators#1286)
- Switch to `uv_build` build backend. (openapi-generators#1290)

Co-authored-by: knope-bot[bot] <152252888+knope-bot[bot]@users.noreply.github.com>

Release 0.25.2 (openapi-generators#1279)

> [!IMPORTANT]
> Merging this pull request will create this release

## Fixes

- Import error for `types.FileType` (openapi-generators#1274) (openapi-generators#1278)

Co-authored-by: knope-bot[bot] <152252888+knope-bot[bot]@users.noreply.github.com>

Release 0.25.1 (openapi-generators#1273)

> [!IMPORTANT]
> Merging this pull request will create this release

## Fixes

- Support ruff 0.12 (openapi-generators#1270)

Co-authored-by: knope-bot[bot] <152252888+knope-bot[bot]@users.noreply.github.com>

Release 0.25.0 (openapi-generators#1267)

> [!IMPORTANT]
> Merging this pull request will create this release

## Breaking Changes

- Raise minimum httpx version to 0.23

### Removed ability to set an array as a multipart body

Previously, when defining a request's body as `multipart/form-data`, the
generator would attempt to generate code
for both `object` schemas and `array` schemas. However, most arrays
could not generate valid multipart bodies, as
there would be no field names (required to set the `Content-Disposition`
headers).

The code to generate any body for `multipart/form-data` where the schema
is `array` has been removed, and any such
bodies will be skipped. This is not _expected_ to be a breaking change
in practice, since the code generated would
probably never work.

If you have a use-case for `multipart/form-data` with an `array` schema,
please [open a new
discussion](https://github.com/openapi-generators/openapi-python-client/discussions)
with an example schema and the desired functional Python code.

### Change default multipart array serialization

Previously, any arrays of values in a `multipart/form-data` body would
be serialized as an `application/json` part.
This matches the default behavior specified by OpenAPI and supports
arrays of files (`binary` format strings).
However, because this generator doesn't yet support specifying
`encoding` per property, this may result in
now-incorrect code when the encoding _was_ explicitly set to
`application/json` for arrays of scalar values.

PR openapi-generators#938 fixes openapi-generators#692. Thanks @micha91 for the fix, @ratgen and
@FabianSchurig for testing, and @davidlizeng for the original report...
many years ago 😅.

Co-authored-by: knope-bot[bot] <152252888+knope-bot[bot]@users.noreply.github.com>

Release 0.24.3 (openapi-generators#1236)

> [!IMPORTANT]
> Merging this pull request will create this release

## Features

### Adding support for named integer enums

openapi-generators#1214 by @barrybarrette

Adding support for named integer enums via an optional extension,
`x-enum-varnames`.

This extension is added to the schema inline with the `enum` definition:
```
"MyEnum": {
    "enum": [
        0,
        1,
        2,
        3,
        4,
        5,
        6,
        99
    ],
    "type": "integer",
    "format": "int32",
    "x-enum-varnames": [
        "Deinstalled",
        "Installed",
        "Upcoming_Site",
        "Lab_Site",
        "Pending_Deinstall",
        "Suspended",
        "Install_In_Progress",
        "Unknown"
    ]
}
```

The result:

![image](https://github.com/user-attachments/assets/780880b3-2f1f-49be-823b-f9abb713a3e1)

Co-authored-by: knope-bot[bot] <152252888+knope-bot[bot]@users.noreply.github.com>

Release 0.24.2 (openapi-generators#1232)

> [!IMPORTANT]
> Merging this pull request will create this release

## Fixes

### Make lists of models and enums work correctly in custom templates

Lists of model and enum classes should be available to custom templates
via the Jinja
variables `openapi.models` and `openapi.enums`, but these were being
passed in a way that made
them always appear empty. This has been fixed so a custom template can
now iterate over them.

Closes openapi-generators#1188.

Co-authored-by: knope-bot[bot] <152252888+knope-bot[bot]@users.noreply.github.com>

Release 0.24.1 (openapi-generators#1221)

> [!IMPORTANT]
> Merging this pull request will create this release

## Features

- allow Ruff to 0.10 (openapi-generators#1220)
- allow Ruff 0.11 (openapi-generators#1222)
- Allow any `Mapping` in generated `from_dict` functions (openapi-generators#1211)

## Fixes

### Always parse `$ref` as a reference

If additional attributes were included with a `$ref` (for example
`title` or `description`), the property could be
interpreted as a new type instead of a reference, usually resulting in
`Any` in the generated code.
Now, any sibling properties to `$ref` will properly be ignored, as per
the OpenAPI specification.

Thanks @nkrishnaswami!

Co-authored-by: knope-bot[bot] <152252888+knope-bot[bot]@users.noreply.github.com>

Release 0.24.0 (openapi-generators#1210)

> [!IMPORTANT]
> Merging this pull request will create this release

## Breaking Changes

### Support `$ref` in responses

Previously, using a `$ref` to define a response was ignored, the code to
call the endpoint was still generated, but
the response would not be parsed. Now, responses defined with `$ref`
will be used to generate the response model, which
will parse the response at runtime.

If a `$ref` is incorrect or uses a feature that is not supported by the
generator, these endpoints will start failing to
generate.

## Features

### Make `config` available in custom templates

The configuration options object is now exposed as a variable called
`config` in Jinja2 templates.

### Add `docstrings_on_attributes` config setting

Setting this option to `true` changes the docstring behavior in model
classes: for any attribute that have a non-empty `description`, instead
of describing the attribute as part of the class's docstring, the
description will appear in an individual docstring for that attribute.

Co-authored-by: knope-bot[bot] <152252888+knope-bot[bot]@users.noreply.github.com>

Release 0.23.1 (openapi-generators#1195)

> [!IMPORTANT]
> Merging this pull request will create this release

## Features

- allow Ruff 0.9 (openapi-generators#1192)

Co-authored-by: knope-bot[bot] <152252888+knope-bot[bot]@users.noreply.github.com>