Proposition: switching to semantic versioning

[ales-tsurko]

It would be simpler to understand the state of a release with the semantic versioning instead of the current one (does it has breaking changes? new features? or is it a bugfix release?).

[stevedekorte]

I didn't use semantic versions because I didn't see how to objectively judge the difference between the numbers e.g. patches are objective, but one person's 1.0.X is another person's 0.1.X Another example: you mention "does it have breaking features"? What numeric designator consistently indicates that in "semantic" versioned apps? Are minor version changes never incompatible?

Anyways, I'm open to changing it if you recommend it and it won't break Io's releases via the package managers that currently support it.

[ales-tsurko]

To avoid such confusions we could follow this convention:
X.0.0 — major changes, that have incompatibilities with the current API;
1.X.0 — have new features, but compatible with the current API;
1.0.X — bugfix release.

[ales-tsurko]

@stevedekorte I'm going to do some Io and Eerie job on the weekend and one thing I'd like to do is updating the version in the interpreter (and everywhere else). Besides from the points I'd said in this issue, I'd add to semantic versioning the fact that it is dominating versioning system and using it would make simpler integration with possible libraries and package managers.

I suggest to start with Io version 1.0.0. The API is quite stable and it's been a long in development so Io deserves it. Eerie already uses semantic versioning and its version is 0.2.0 now.

Are you ok with it?

[stevedekorte]

Will this cause any issues with existing package systems thinking the newer version is an older version because the numbers are lower?

[ales-tsurko]

Yeah... This is a problem. But while we can fix it saying here and there in README and the docs "use this not that" there's a worse issue with the current versioning system.

For example, I'd like to depend on Io. And I don't want any breaking API changes in this dependency and I'm fine with the current feature set or implementation details. With semantic versioning I'd write something like "^1.0" in my package manager's manifest file or something alike. This way I'd get updates on it with all patch releases (1.0.1, 1.0.2, etc.) until Io updates to 1.1.0. And it is a clear intention of a version. I get what I want. And If I'd also like to include new features, for example, or I'm fine with small refactoring I'd write "^1". So the package would be updated until new version with some breaking API changes released.

With current versioning system the intentions are unclear. It's unknown which changes a version has: is it a patch, small change or something breaking? Also, we depend on time. We could make a patch release in the next few months, for example, but for a major part of package managers this would look like we did a breaking API change.

And things get even worse at scale. For example Io becomes so successful some company considers using it for their microservice. But they can't. Because not only the command, which would work on this microservice, but dependents on this microservice too, can't rely on a specific Io version. They forced continuously update with each new version of Io.

Semantic versioning would make Io easier to depend on.

[stevedekorte]

Good points. I agree :)