Document versioning policy

[orbitbot]

Since Mithril doesn't follow Semver, but uses a similar numbering scheme post a 1.0.0 release, it would be appropriate to state what the versioning policy is somewhere. As mentioned elsewhere, Semver has specific rationale and deviating from that in undocumented ways mainly causes grief. Intentionally or unintentionally the previous release seems to actually have been compatible from what I can tell at a glance.

[dead-claudia]

@orbitbot It's not documented anywhere yet, but we've informally agreed to a semver-ish policy until the new API stabilizes. Basically, we aim for semver conformance, but with some practical flexibility in case we overlooked some design flaw where fixing it is breaking, but not outright treacherous. In particular, the proposed change to m.request URL interpolation, although technically semver-major, might wind up in a minor update depending on how the other maintainers view it. Also, this proposal would likely land in a patch change, since it's a small addition (defining previously undefined behavior).

[orbitbot]

Yeah, my concern is mainly that a fix for #1691 , f.e. as suggested in https://github.com/lhorie/mithril.js/issues/1691#issuecomment-287030203 - would slip through in a minor bump without reasoning, since those related fixes while simple to achieve are quite fundamental in functionality change.

[dead-claudia]

@orbitbot Note that I said "might", not "will". And in particular, we won't break on a minor bump unless the existing functionality is highly unintuitive to begin with, and people generally expect the latter. We also try to minimize the breaking changes we do make - technically, the component additions were mildly breaking, but few people actually used functions as components previously, so that affected almost nobody. (We almost had a semver-major break by accident due to our reliance on vnode.state, but it was fixed in #1746 right before release.)