v3.0: set up schema maintenance
Prepare development branch for v3.0 schema maintenance:
- [x] create branch
v3.0-dev-wip- diff todev - [x] delete
src/oas.md- we do not plan a 3.0.5 spec release- [ ] otherwise: #5094
- [x] delete
src/schemas/validation/* - [x] move
_archive_/v3.0/schemas/schema.yamland accompanyingREADME.mdtosrc/schemas/validation/ - [x] move test-related files from
_archive_/v3.0/schemas/totests/ - [x] make tests work and pass
- [x] refactor tests to use same tools as the v3.1 tests
- [x] test schema publishing workflow - also works for 3.0
- [x] adjust selected 3.1 pass/fail test cases to increase schema coverage
- [ ] rename branch
v3.0-dev-wiptov3.0-dev(or squash-merge it into a branch freshly created fromdev)
@ralfhandl we have not resolved #4865 regarding a 3.0.5 or errata, and I am still concerned about 3.0.4 misleading tooling developers and complicating the upgrade path. We should not do anything to preclude a 3.0.5 at this time.
I don't think we should commit to maintenance for EOL branches.
I'm still not giving up on fixing the accidental but egregious errors (giving the completely wrong instructions on handling URI percent-encoding in header parameters, for example, in ways that will cause tooling incompatibilities) in 3.0.4.
@lornajane @ralfhandl of course if we solve the 3.0.4 issues with errata instead of a 3.0.5, we could hot-patch the errata links on main rather than having a v3.0-dev (as we could, in theory, hot-patch a schema fix somehow if we want to). Anyway, that debate belongs in #4865, I just replied here because @lornajane brought up the broader philosophical point here.
I think we should enable @karenetheridge to fix bugs in the 3.0 schema.
I do not want to preclude a 3.0.5 spec release, nor do I want to encourage it.
Having no spec source file in the 3.0 schema maintenance branch seems a good middle ground that allows both possible futures.
@lornajane @ralfhandl let's take this broader discussion to #4865. I will write an updated summary of my position there.