So I was learning about forward compatibility, and I was wondering if you could warn a "dependent" that a dependency is backward compatible, but not forward compatible*, and vice-versa.
The SemVer specification requires that:
7. Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality [emphasis mine] is introduced to the public API. [...]
8. Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY include minor and patch level changes. [emphasis mine] [...]
To me, it means that:
- You must increment the minor version when you do a backward compatible but not forward compatible* change. Indeed, if you introduced a "new [...] functionality [...] to the public API" and dependents upgrade the dependency and use it, the dependency can't guarantee that downgrading won't break any dependent, as a mirrored version of backward compatibility. So adding a "new [...] functionality [...] to the public API" is backward compatible and not forward compatible*, and I make the supposition that any backward compatible and not forward compatible* change is, in a way, adding "new [...] functionality [...] to the public API", because I don't see any counter-example (and other reasons I could explain if needed), making them basically equivalent.
- You must increment the major version when you do a not backward compatible change. It can be forward compatible*, or not.
- You must increment the patch version when you do a backward compatible and forward compatible* change, by elimination (and the same other reasons I could explain if needed).
Suppose that I'm right, and that any change that is both not backward compatible and not forward compatible* can be separated into two successive changes, one backward compatible and the other forward compatible* (or the other way around).
It would mean that you could always separate the not backward compatible but forward compatible* changes from the others, and never have a change that is both not backward compatible and not forward compatible*.
So you could redefine:
- the major version as a forward compatible* version including at least one not backward compatible change
- the minor version as a backward compatible version including at least one not forward compatible* change.
It would mean that any new major version
M.0.p of a dependency can be downgraded safely by dependents, even until the last minor version of the preceding major version, let's call it
Suppose that I'm right.
Would it be beneficial or useless to the dependents to know that a version of a dependency is guaranteed to be forward compatible*?
What would be the pros and cons of that additional constraint to SemVer?
(verifying my reasoning is not the purpose of this question, I know that I'm overthinking, but I just want to know if this reasoning is useful in any way or not, however I would appreciate to have your opinion)
EDIT: Anywhere there is a "*" after "forward compatible", I meant "safely downgradable".
Indeed, when a version is backward compatible, it means that the previous version is safely upgradable. So when a version is forward compatible, it means that the next version is safely downgradable. It also means that you can't guarantee that a version is forward compatible before the next version is out. So you can guarantee that a new version is backward compatible or safely downgradable, but you can't guarantee that it's forward compatible or safely upgradable yet.