misssing a revision number, date not YY.MM.DD

[kitty624]

• when adding the c'n'c-stuff to source, GameVersion.cpp has seen no update, so we're one number behind

• the comment in GameVersion says YY.MM.DD but the entry is DD.MM.YY

• should we even fix the revision number (add up two numners next time?) ?

• should we go back to previous kind of date in next commit (yy.mm.dd) ?

• mentioning because i plan to upload a SCI and would like to keep the old naming convention

[Asdow]

I would just continue from the current revision number. The cnc related code change will have no noticeable effect on anyone not having both cnc-ddraw and set the game to windowed in ja2.ini. The game's own windowing mode will then be fullscreen which makes the game still work.

The date format should be corrected on the next commit to be inline with the comment

[rftrdev]

Should we abandon the SVN revision number naming scheme? I've got no dev ops experience, but I'm doing a little bit of reading on potential Jenkins replacements. What I've got in mind is:

1. CI pulls 1dot13 source
2. CI runs a post-pull script to create a file to be included with the build, containing the date and latest commit hash
3. CI builds 1dot13 source

The new unstable "version number" would be defined by the build date, with the commit hash being a minor version number, something like "2022.10.31-a1b2c3".

The old versioning scheme also has the date in it, so it's still clear that these versions are newer.

[Asdow]

Automating versioning like that would be real nice. That would saves us from manually updating gameversion.cpp

[kitty624]

Automated builds like on Jenkins would be nice.
As I understand, the Jenkins did a build each time a change in either source or gamedir was detected.

So we would need to find a way to reflect changes in both, source and gamedir for a complete release-names (because sometimes there are changes to source only, sometimes to gamedir only and sometimes to both).

From a developers pov, the name containing the commit hash would be nice. From a players pov, that just will look confusing.

I get it, keeping the svn-names probably doesn't make much sense anymore, but people are used to the SVN naming for nearly 20 years, any change needs to be advertized/explained properly. It's like giving up an established brand name.

I see strac is using a version number (v0.19 etc) , so how about adding one?
Like "ja2 v1.13 v9108 yyyy.mm.dd (hash source/hash gamedir)".
With the version number still continuing the numbers players are used to and all other aditional info developers want to have for dealing with bug reports and the like?

Does that sound reasonable?

[rftrdev]

Stracciatella's versioning comes from a collection of commits and is done manually. We could do something similar here by tagging a specific commit as a release version, meaning we would have "stable" builds again. What I'm proposing is roughly equivalent to a naming scheme for nightly builds (ie, "unstable").

The main issue with continuing SVN's revision count is that git doesn't really have a concept of an incremental commit counter, so one would have to be maintained as part of the project.

[Asdow]

Shouldn't it be possible to do something like that with CI? This is the part where my lack of devops rears its head.

I do agree with Kitty that the running revision count is by now pretty established for 1.13 and is a really quick way to determine how old a build is in terms of commits, but manually keeping it up to date is an exercise in futility