As I was afraid, build OoliteInstall-1.91.0.db08f87-dev.exe runs OK, but OoliteInstall-1.91.1.21c1a54-dev.exe fails to run. The reason for the failure is that info-gnustep.plist contains "1.91" as the string for the CFBundleVersion key, when it should contain "1.91.1". However, the version should not be automatically bumped to 1.91.1 between builds.
In order to answer your questions, let ne explain how our current versioning scheme works to the best of my knowledge:
A complete Oolite version string consists of six components. The first three are mandatory and are what is used for GitHub tagging, release generating and overall application version reference. These three need to be set up correctly for the game to work, as we are witnessing at this time. The remaining three components are there for developer assistance and are used to uniquely identify the exact code commit that produced an executable and provide a 1-to-1 correspondence between a specific binary and the code that created it. The image below explains it further:
1.Major: This has been set to 1 since the first release, some 17 or more years ago. We don't expect it to go to 2 unless someone rewrites Oolite from scratch or modifies the game's structure down to the lowest level possible. Not something that is expected any time soon.
2. Minor: This number is important. It is even for stable releases and odd for development ones. Currently we are at 91, which is a version under development. This number gets bumped before a stable release (e.g. it will be bunmped to 92 for the next one), the release is made and then this number is immediately bumped again (e.g. 93 in our case) to denote the next development cycle.
3. Patchlevel: This is set to 0 under normal circumstances. Consider this scenario: We have released 1.92 (which is the same as 1.92.0 for our purposes) and we suddenly find out that we shipped it with a major show-stopping bug in. Let's say it takes us 6 code commits until we have a proper fix ready. Now what we want to do is bump the patchlevel version number to 1 and ship 1.92.1 asap so that the problem is sorted out. That's an example where the patchlevel will have to be bumped manually and thankfully is a rare occurrence. But this is how we would use it and our version number would be 1.92.1 and not 1.92.6. Just because it took us 6 code commits to fix an issue doesn't mean that we will be bumping patchLevel 6 times.
The above three numbers need to be correctly reported in the game files, mainly because of how GNUstep handles them. There is not much we can do about it ourselves, it seems to be related to the internal workings of our core support libraries. The components above are what is normally presented to users and how we normally describe our versions (e.g. our last release is 1.90, our current trunk is 1.91 and if we need a bugfix patch after the next version comes out it will be 1.92.1, while if we need a second bug fix it would become 1.92.2). Note that a 0 as the last version component can be ommitted and e.g. 1.91 is treated the same way as 1.91.0. Now let's go to the non-compulsory components. What is described below is reported in the Windows port and I am not sure if all of this is also reported under the other ports fully or partially. But these ones are optional anyway, so it doesn't matter if some minor differences exist.
4. Incremental build number: Whenever there is a commit on github, it receives an internal incremental number regardless of which branch or PR it was pushed to. Because of this, said component can be used to uniquely identify a commit. Also, this is how SVN used to assign commit numbers in the past and Oolite started on SVN, so we kept the incremental build number as a continuation of the old system.
5. Date of build: This is in YYMMDD format and it helps us locate the time a build was made. Note that it does not tell us when a particular commit was made, but when the binary was compiled, which could be some time after the corresponding commit was pushed to github (but when it comes to the automated releases, this is not normally a consideration as those are made immediately after a commit). Still, it can be helpful with investigating issues.
6. GitHub hash #: This is there so that we can easily search for a particular commit on github based on its hash, which is the info github publishes in order to refer to a specific commit. It immediately lets us know where in the codebase we need to look at when a user reports a bug or other problem.
This scheme has been established for many years and it has been proven to serve us pretty well till now. Automating this is fine, but the "rules" for bumping a version should respect the established practices. Interfering with the versioning scheme is much more easily done for a new project, but for one that's been going on for almost 20 years, one has to tread very carefully to avoid confusion.
