About versioning scheme.

[KelSolaar]

Just to start a discussion about the versioning scheme, for now as the API is in alpha phase I don't really have a specific versioning scheme in mind. However when the first 1.0.0 version is released, we will have to adopt a kind of strict versioning scheme, one that came to my mind is the semantic versioning: http://semver.org/

Only thing I don't really like is the fact the major version can really get high very quickly: Changing a public object name or its signature would result in a major version bump, for instance going from 1.3.5 to 2.0.0.

[KelSolaar]

Here is how Ruby is doing it:

major.minor.teeny.patch

https://www.ruby-lang.org/en/news/2013/12/21/ruby-version-policy-changes-with-2-1-0/

[MichaelMauderer]

I think coupling releases to Christmas is a bad idea. Religions can change over time and let's not even get started with the discussion about whether "Christmas" refers to "Christmas Eve" or "Christmas Day"(even though the later is clearly wrong). Overall something like the southern hemisphere summer solstice would be much more suitable to give an objective point of reference.

...what I mean is: I vote semantic versioning.

I think the issue about the rapidly increasing version number is nicely addressed in the FAQ on the site itself: "Incompatible changes should not be introduced lightly to software that has a lot of dependent code."

Comparing semantic versioning and Ruby, it seems that in the Ruby scheme the first version number is more of a marketing gimmick than anything really meaningful.

[KelSolaar]

Allright! Let's go for that when we hit stable in a few releases.