enforce semver major version when publishing package

[andrewrk]

When we publish a zig package we have access to the previous version. We know all the published declarations of the package of both versions. Therefore we know if the API changed in a backwards incompatible way. If it did change in a backwards incompatible way, we should emit an error if the major version is not bumped.

[thejoshwolfe]

When we publish a zig package we have access to the previous version.

Is this still true with the distributed package manager proposal?

[andrewrk]

No, this issue needs to be reworked given the current package manager proposal. However, it is still relevant - we can provide tools to compare API compatibility, and figure out in what ways we can enforce them. At the very least, the tool could assist the upgrade process - for example when deciding to upgrade you could query the system to see what API changes - that you actually depend on - happened between your current version and the latest.

[andrewrk]

I don't think it will be possible to realistically enforce semver major version bumps, especially when what exactly is considered a breaking change can be an elusive concept that is communicated only in the documentation. For example, is the size of a struct part of the major version? Maybe, maybe not. It's the library author's job to communicate this information.

I do think we can add tools related to this which can help library authors understand what possibly breaking changes they have introduced, but that should be a separate, more detailed and focused, proposal.