Presently, the Metadata-Version section of the core metadata spec states:
For broader compatibility, build tools MAY choose to produce distribution metadata using the lowest metadata version that includes all of the needed fields.
Following discussion on PEP 685’s thread and related conversations on metadata-version, it seemed prudent to simply remove this.
It implies that there are multiple discrete, current, valid versions of the spec at any given time, rather than just one canonical version, with existing already-produced metadata following older versions. Furthermore, later versions of the spec contain more than just new fields, but also important clarifications, refinements and even deprecations of existing ones (e.g. PEP 685). Implicitly suggesting that tools use older versions just because they don’t use particular fields also means they don’t adopt such corrected behavior, producing more out of date metadata and creating a greater backward-compat issue in the long run. Simply removing this would avoid the confusion it causes in spec discussions and the implication that metadata producers should not be using the latest version (i.e. what’s actually in the packaging guide).
Per @pfmoore :
I would prefer to drop the quoted statement, and let the whole thing come under the “be strict in what you produce and lenient in what you consume” principle, so that metadata producers should always produce the latest version that they can, and consumers should be capable of dealing with older versions.
What do others in the packaging community, particularly tool maintainers, think about this? Are there any reservations to implementing this as a PR to the spec, pypa/packaging.python.org#1063?
