PEP 825: use semantic versioning for the schema version

[mgorny]

Expand the schema versioning to strictly follow semantic versioning. That is, major versions represent breaking changes and require tools to reject incompatible versions, whereas minor versions represent backwards compatible changes and permit tools to accept them.

[mgorny]

That said, this makes me wonder if we need to be explicit about allowing additional keys all over the place then.

[mgorny]

Hmm, actually this may need even more thinking. Even if we allow installers to install "newer backwards-compatible versions", this opens up the question of whether indexes should allow them. And if they do, how do they combine metadata if they don't necessarily know the keys?

[read-the-docs-community]

Documentation build overview

📚 wheelnext-peps | 🛠️ Build #33799422 | 📁 Comparing 8c23a40 against latest (0cde95d)

  🔍 Preview build  

751 files changed · + 2 added · ± 749 modified

+ Added

• pep-0835/index.html
• pep-0836/index.html

± Modified

• 404.html
• index.html
• api/index.html
• contents/index.html
• docs/index.html
• numerical/index.html
• pep-0000/index.html
• pep-0001/index.html
• pep-0002/index.html
• pep-0003/index.html
• and 739 more...

[rgommers]

That said, this makes me wonder if we need to be explicit about allowing additional keys all over the place then.

I don't think so. Additional keys should not be allowed when authoring unless there's another PEP for them, similar to Core Metadata. Meaning that if there's extra keys in .json content, they came from out-of-spec meddling which is UB pretty much by definition. In practice, extra keys will be allowed given that there's no other way to accept compatible minor versions.

Even if we allow installers to install "newer backwards-compatible versions", this opens up the question of whether indexes should allow them. And if they do, how do they combine metadata if they don't necessarily know the keys?

Indexes should be strict, and explicitly updated for every minor version. They fall on the publishing side. I think this 100% mirrors how it's done for Core Metadata.

[rgommers]

https://packaging.python.org/en/latest/specifications/core-metadata/#metadata-version

I'm not sure if that's actually reflecting how it works in practice, I don't think pip warns on newer core metadata (didn't check that, just have never seen it).

[konstin]

Indexes should be strict, and explicitly updated for every minor version. They fall on the publishing side. I think this 100% mirrors how it's done for Core Metadata.

We can make this explicit in the rational section that we're using the established practices from METADATA, that makes the explaining easier.

[mgorny]

Split the tool types, and extended the rationale — also shortly explaining why it's a separate file.

I suppose we may want to have a specific list of tool classes that we need to account for. However, that's a non-trivial task, and I'm not sure if it wouldn't end up being too fine-grained in the long run.

[konstin]

I'd say trust the tool authors, they know what they are doing and in which class they are. As a person on the other side, the many SHOULDSs or classifications in PEPs aren't helpful, they usually miss the actual big problems in implementations.

[rgommers]

LGTM now

[rgommers]

I'd say trust the tool authors, they know what they are doing and in which class they are.

I agree, just the split in producing/consuming tools is useful enough, especially if the rule is "treat the same as Core Metadata".