You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CHANGELOG.md
+88Lines changed: 88 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,6 +13,94 @@ Programmatic usage of this project (e.g., importing it as a Python module) and t
13
13
14
14
The 0.x prefix used in versions for this project is to indicate that breaking changes are expected frequently (several times a year). Breaking changes will increment the minor number, all other changes will increment the patch number. You can track the progress toward 1.0 [here](https://github.com/openapi-generators/openapi-python-client/projects/2).
15
15
16
+
## 0.26.1 (2025-09-13)
17
+
18
+
### Features
19
+
20
+
- Reference schema support (#800) (#1307)
21
+
- Support Ruff 0.13
22
+
23
+
## 0.26.0 (2025-08-26)
24
+
25
+
### Breaking Changes
26
+
27
+
#### Change some union variant names
28
+
29
+
When creating a union with `oneOf`, `anyOf`, or a list of `type`, the name of each variant used to be `type_{index}`
30
+
where the index is based on the order of the types in the union.
31
+
32
+
This made some modules difficult to understand, what is a `my_type_type_0` after all?
33
+
It also meant that reordering union members, while not a breaking change to the API, _would_ be a breaking change
34
+
for generated clients.
35
+
36
+
Now, if an individual variant has a `title` attribute, that `title` will be used in the name instead.
37
+
This is only an enhancement for documents which use `title` in union variants, and only a breaking change for
38
+
_inline models_ (not `#/components/schemas` which should already have used more descriptive names).
39
+
40
+
Thanks @wallagib for PR #962!
41
+
42
+
### Features
43
+
44
+
#### Support patterned and default HTTP statuses
45
+
46
+
HTTP statuses like `2XX` and `default` are now supported!
47
+
48
+
A big thank you to:
49
+
-@PSU3D0 for PR #973 (eons ago 😅)
50
+
-@obs-gh-peterkolloch for PR #1300
51
+
-@goodsonjr for PR #1304
52
+
53
+
Closes #1271 and #832
54
+
55
+
> [!NOTE]
56
+
> Custom template users: the `endpoint.responses` type has changed quite a bit. Check out #1303 for the changes.
57
+
58
+
## 0.25.3 (2025-07-21)
59
+
60
+
### Features
61
+
62
+
- Add --meta uv for generating astral-sh/uv compatible packages. (#1286)
63
+
- Switch to `uv_build` build backend. (#1290)
64
+
65
+
## 0.25.2 (2025-07-03)
66
+
67
+
### Fixes
68
+
69
+
- Import error for `types.FileType` (#1274) (#1278)
70
+
71
+
## 0.25.1 (2025-06-19)
72
+
73
+
### Fixes
74
+
75
+
- Support ruff 0.12 (#1270)
76
+
77
+
## 0.25.0 (2025-06-06)
78
+
79
+
### Breaking Changes
80
+
81
+
- Raise minimum httpx version to 0.23
82
+
83
+
#### Removed ability to set an array as a multipart body
84
+
85
+
Previously, when defining a request's body as `multipart/form-data`, the generator would attempt to generate code
86
+
for both `object` schemas and `array` schemas. However, most arrays could not generate valid multipart bodies, as
87
+
there would be no field names (required to set the `Content-Disposition` headers).
88
+
89
+
The code to generate any body for `multipart/form-data` where the schema is `array` has been removed, and any such
90
+
bodies will be skipped. This is not _expected_ to be a breaking change in practice, since the code generated would
91
+
probably never work.
92
+
93
+
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.
94
+
95
+
#### Change default multipart array serialization
96
+
97
+
Previously, any arrays of values in a `multipart/form-data` body would be serialized as an `application/json` part.
98
+
This matches the default behavior specified by OpenAPI and supports arrays of files (`binary` format strings).
99
+
However, because this generator doesn't yet support specifying `encoding` per property, this may result in
100
+
now-incorrect code when the encoding _was_ explicitly set to `application/json` for arrays of scalar values.
101
+
102
+
PR #938 fixes #692. Thanks @micha91 for the fix, @ratgen and @FabianSchurig for testing, and @davidlizeng for the original report... many years ago 😅.
Copy file name to clipboardExpand all lines: end_to_end_tests/__snapshots__/test_end_to_end.ambr
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@
6
6
7
7
WARNING parsing GET / within default.
8
8
9
-
Invalid response status code abcdef (not a valid HTTP status code), response will be omitted from generated client
9
+
Invalid response status code pattern: abcdef, response will be omitted from generated client
10
10
11
11
12
12
If you believe this was a mistake or this tool is missing a feature you need, please open an issue at https://github.com/openapi-generators/openapi-python-client/issues/new/choose
0 commit comments