I’ve utilized the Major.Minor format as SemVer standard typically follows a Major.Minor.Patch scheme, which demands three uints returned. This seems overkill to me. Note, I’m not discussing subversions here - your strategy is sound for those.
What I’m focusing on are instances where provisional versions conflict with the final one. For example, while implementing ERC-6551 in Cruna Protocol, I’ve encountered an issue. The interface IERC6551Account requires the implementation of:
function owner() external view returns (address);
This should return the token-bound account owner. However, it conflicts with the owner() function needed by EIP-173 or EIP-5313 for contract ownership. A comprehensive discussion can be found starting from this link.
My suggestion is renaming the function to:
function accountOwner() external view returns (address);
This change resolves the conflict but breaks compatibility with existing implementations due to the interfaceId alteration. While ERC-165 can’t fix this, ERC-5269 may provide a solution.
Consider defining the current ERC-6551 version as 0.1. If the function is renamed causing a new interfaceId, we could call that version 0.2. Eventually, there will be a finalized version 1.0. With my proposal, the caller receives (0, 1) if the contract implemented the draft version, and (0, 2) or (1, 0), depending on contract deployment timing if the contract implemented latest version.
This approach eliminates ambiguity, making it easier for ERC-6551 proponents to modify their interface, even if it’s already in production.