Suggestion: Version numbering changes

I would like to humbly suggest a simple change to the version numbering used on Espruino.

Right now, unless you start digging, something compiled from github is hard to tell apart from the next released version. Have you thought about doing something like what apache does. They use even numbers for "stable" releases, and odd numbers for development ones.

IE, the process I would propose is:
*Release version 80 (even number, release)
*Immediately bump version to 81
*Commit changes normally
*bump version to 82, then immediately release
*bump version to 83 immediately (and so on)

That way, if we see an odd numbered build, we know it's "between" two released versions - so when someone says "This works with v82 and later", we won't need to know if we used a github build for v82, because all the github builds will be either v81 or v83.

Of course, there are many ways to achieve the same effect - I just don't think the current situation, where "you need v82" really means "you need the release v82, not a github v82 which looks the same".

Do other people like this idea?

Any removal of ambiguity helps... and that is an easy way to for clear separtion from 'frozen version' and 'versions in motion'.

A simple link could then also be provided in the reference/documentation to get a hold of the most recent 'version in motion'... of course, needs to be updated on every build.

Also, mixing that with semantic versioning would be just perfect.

Thanks - yes, I wonder whether I should change the build such that it's:

Major.Minor.GitCommitsSinceRelease

(and then I only increase the minor version number when I actually do a release, so 1.79.6 is an older build than 1.80)

That probably wouldn't end up being too difficult to do...

I'm not so sure about semantic versioning... I think there still needs to be the idea of an actual release, as I don't want people to get an upgrade prompt every time a commit gets put into Git - also sometimes changes that don't add to or break the UI are still important enough that they require an almost immediate release.

Didn't think about the update prompt... it of course has to be adjusted to new semantics... I think to add an extra zone / segment in the number - .GitCommitsSinceRelease - makes it more clear and easier to handle.

Major.Minor.Gitcommits works for me. That may be more graceful (my above suggestion was just the smallest change I could think of to the current policy that would address my concern.

Really, what I was suggesting basically boiled down to "anything to make it hard to confuse the first github build of v80 after v79 was relesed apart from the v80 release"