Do not bump project's version constantly

[BottledByte]

1. It goes against Semantic Versioning. Bumping last number of version declares there are some bugs fixed compared to the last release, which is not true -> there are no continuous releases to "fix". Also, there are often new features mixed-in.
2. The efficiency of differentiating builds is still very low compared to a proper solution.
3. It adds worthless commits, only making Git history messy.

I see no issue with bumping the minor version number (?.X.?) to the next expected release version, after current release is tagged and deployed in Github Releases. So next commit after releasing 0.25.0 will be to bump the version to 0.26.0 until next release, when the 0.26.0 will be bumped to 0.27.0 and so on.

@tuomount If you desperately want to differentiate between development builds, proper way to do that is by using Git commit identifiers in version strings. It is both more useful and can be automated. But I see absolutely no need for it as of now, as the project does not have continuous releases anyway.

And to emphasize the issue and why this bumping should NOT be done further, here are some numbers:

1. Running git log | grep "Update version to " | wc --lines reports there is 902 such version bumping commits.
2. This is more that 35x times more version updates than released versions!
3. Such commits make 17% of all commits in the project! (As of now, with 5199 commits)

I was amazed by the numbers when I looked into history 😄

EDIT: I forgot to add that it also confuses packaging to ZIP when I have more differently versioned builds in /target directory. It will pack all previous JAR files I have there into the ZIP, marked with latest version.
I do not run mvn clean very often and maybe I should 🙂 , but still it worth mentioning as a minor related issue.

[tuomount]

Idea was that only stable versions have published releases. I think that those version between stable ones should be distinct somehow. How git commit identifier could be get into version number? I would guess it would require some plug-in to maven. For example 0.24.21Beta-c6705cbf would be excellent. I admit that I have been quite lazy with Maven, and I even found it is easier to manually pump up third number in version everyday when I make changes, than looking for maven plug-in for it. 😄

Another thing I would like to have is that there would another command like mvn verify, but it would not run full game JUnits since those can take quite a time depending on your CPU. But those are good when making AI changes or something else big game feature changes.

[BottledByte]

For example 0.24.21Beta-c6705cbf would be excellent

I can offer you to have ?.?.?-SNAPSHOT version label format for local developer builds and ?.?.? for official GitHub Releases, where you have to do only 1 commit with version bump per release cycle, each time after you do a GitHub Release. You would just have to run release build with different command (since you do Releases by hand). This includes propagation of this information to the Game itself.

I can also make it that there is no version bump commit per release cycle and developer builds will be marked with Git commit SHA. No modifying version strings ever again. But will have to get me access to CI for that 😉

So, no more "daily version bump" commits?
And will you let me remove that Beta version suffix while at it? IMHO, it looks bad. 😄
You accept? 😉

[tuomount]

Let's go with ?.?.?-SNAPSHOT and one version bump per release cycle. I am also okay removing the Beta version suffix.

[BottledByte]

@tuomount After release, it is necessary to update src/resources/resource/changelog.txt also with heading that has the version string of the last released version.

Without this, the changelog in game will look like this for developer builds, not mentioning the last released version:

Otherwise, I can confirm that in released version 0.25.0 the changelog looks OK. 👍

And congratulations to the release of 0.25.0. 🎉
... I will start sending more PRs. 😄

[tuomount]

Update 0.25.0 into changelog. Change log is now just empty for 0.26.0. I was thinking to add that title there when we actually have something for change log, but there is always a chance it forgets from there, like 0.24.0Beta was forgotten from the change log. Closing this one.