You are reading a single comment by @DrAzzy and its replies.
Click here to read the full conversation.
-
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"
DrAzzy
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.