Skip to content

v3.2.1 release #5460

Open
Open
v3.2.1 release#5460
Assignees
lornajane

Description

@karenetheridge
karenetheridge
opened on Aug 1, 2026

This issue requires TSC signoff in order to complete.

  • schema changes since last schema release (2025-11-23) consist of various fixes to be better aligned with the specification:

    • contentType format fix (now allows comma-separated values)
    • propertyName is required in the discriminator object
    • ABNF applied for path parameter names, header names, request method names
    • style, explode, allowReserved existence and defaults now better enforced
    • adjacent query, querystring parameters are prohibited

  • spec changes since 3.2.0 release:

    • more cross-references to RFCs and other sections of the specification
    • clarification of how paths are matched when a template variable contains a "/"
    • corrections to the table of Style Examples (used in parameter encoding)
    • we now explicitly note more in/style/explode combinations that are prohibited, namely:
      • in: cookie, style: form, explode: false with arrays or objects
      • style: form, explode: true with arrays or objects in encoding objects (application/x-www-form-urlencoded or multipart/* message bodies)
    • corrections to descriptions of how encoding objects are used, such as the use of prefixEncoding and itemEncoding with data modelled as an array, and usage of contentType together or separately from a Content-Type header in a message part
    • addition of an ABNF for the encoding/<name>/contentType field

Activity

  1. miqui commented on Aug 2, 2026

    @miqui
    miqui
    on Aug 2, 2026
    Contributor

    TSC votes:

    • Yes, Miguel

    Request was made to TSC slack thread as well.

  2. lornajane commented on Aug 3, 2026

    @lornajane
    lornajane
    on Aug 3, 2026
    Contributor

    A yes vote from me!

  3. earth2marsh commented on Aug 3, 2026

    @earth2marsh
    earth2marsh
    on Aug 3, 2026
    Member

    Thanks for the summary of changes. They all sound good, and given that patch releases are meant to be small in nature, I'm happy to give a yes vote to move the process forward. 👍

    As an aside, one thing that I'm not confident I understand is where the biggest risks might be in this release. (I won't hold up the approval process for that, but in general I always like the case against to be given along with the high level framing of why people should appreciate the patch.)

  4. whitlockjc commented on Aug 5, 2026

    @whitlockjc
    whitlockjc
    on Aug 5, 2026
    Member
    • Yes, Jeremy

  5. miqui commented on Aug 5, 2026

    @miqui
    miqui
    on Aug 5, 2026
    Contributor

    Thanks for the summary of changes. They all sound good, and given that patch releases are meant to be small in nature, I'm happy to give a yes vote to move the process forward. 👍

    As an aside, one thing that I'm not confident I understand is where the biggest risks might be in this release. (I won't hold up the approval process for that, but in general I always like the case against to be given along with the high level framing of why people should appreciate the patch.)

    Great point @earth2marsh - will handle this next round!

  6. handrews commented on Aug 5, 2026

    @handrews
    handrews
    on Aug 5, 2026
    Member

    @earth2marsh biggest risks in my view:

    • We could have introduced new errors to the style examples table. however, AFAICT we have never gotten this table right, so it's comfortably within the "almost certainly not worse and very likely to be better" range.
    • The encoding object stuff is complex and has been under-specified, with array usage with form-data particularly confusing, so there's the possibility that the clarifications trip up someone who interpreted it differently. However, many tools don't implement this at all, and it's long been complex and ambiguous without people bothering to complain about it much. So I think we're reasonably safe there.

    All in all, a low-risk release as a patch release should be. Lower than 3.1.1 was, certainly!

  7. lornajane commented on Aug 6, 2026

    @lornajane
    lornajane
    on Aug 6, 2026
    Contributor

    Vote succeeded - we have some infrastructure housekeeping to put in place before we release (and should probably avoid committing to the 3.2 branch in the meantime, or should release from the current commit)

  8. ralfhandl commented on Aug 21, 2026

    @ralfhandl
    ralfhandl
    on Aug 21, 2026
    Contributor
    • Yes

  9. lornajane commented on Aug 27, 2026

    @lornajane
    lornajane
    on Aug 27, 2026
    Contributor

    Continuing the release conversation here: we ran into issues on the call because I didn't have support (on either platform) for running the Chrome dependencies now needed to build the spec files (or maybe just used to check links? I'm not super clear on this)

  10. handrews commented on Aug 28, 2026

    @handrews
    handrews
    on Aug 28, 2026
    Member

    @lornajane so... I think the problem was that I didn't realize I needed to add the /versions/... files to the commit as git commit -a would not pick them up. I'll double-check in the morning and post a release PR if that works out. I'll also fix the build-infra repo to stage the commit instead of requiring the user to do that correctly. But we won't need that fix to make a release here.

  11. lornajane
    self-assigned this
    on Sep 10, 2026

  12. lornajane commented on Sep 10, 2026

    @lornajane
    lornajane
    on Sep 10, 2026
    Contributor

    Things that came up from running the release process that I can't fix now but don't want to forget - we should sort out these or move them to new issues before we close this one. In no particular order:

    • contributing file steps were really good, says that the script stages the changes but we should tell the user to commit
    • I think the publishing process requires us to create a tag on the repo and it's that which gets published - contributing doesn't say to create the tag!
    • I'm not sure if I'm supposed to run through all the start-the-next tag thing now or what (actually I also noticed that the main to dev PR has something in it that I didn't expect dev: sync with main #5550)
    • Tagging doesn't trigger deployment to the spec site. I ran the respec workflow on the OpenAPI repo to see if that would publish things - update: it does! It wasn't perfect, but "run the respec workflow" definitely needs to be included in the updates to the contributing file.
    • [ ]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions