OK. M doesn't mean what I want it to mean but I understand it.
I use "run" in many contexts and I thought I was looking at running a build process on a Mac and not actually trying to run KoLmafia.
I have no idea why anyone would choose to use gradlew runshadow
I did it anyway..
C:\KoLmafia>gradlew runshadow
> Task :runShadow
KoLmafia r25822
Build preferences-5b00322 17 (Oracle Corporation 17+35-LTS-2724) Windows 10 amd64 10.0
Currently Running on Windows 10
Local Directory is C:\KoLmafia
Using Java 17
<===========--> 90% EXECUTING [3m 26s]
> :runShadow
Tangentially runshadow brought up the preferences window on top of the main window which is a very good reason for me not to use the command. It also is not using the same look and feel and main image as my normal run procedure. It is probably because my tree looks like C:\KoLmafia\dist and the default directory for gradle is C:\KoLmafia but all my user files are in or below C:\KoLmafia\dist. I have trained IntelliJ to use the right home but I have no interest in teaching gradle. (The separation comes from over a decade of being able to build on only one machine but being able to run on two different machines and using Dropbox to synch only files needed to run, including the jar).
Bottom line, though is what I had hoped for when we discussed revision numbering is not happening. I would have dragged my feet harder on the switch if I had expected this :-(
The reason it is important is that if user reports a problem with rxyzzy and I want to try and replicate it on my system I don't know how to do that with confidence. Indeed if rxyzzy is the latest on main I can build something labelled rxyzzy in several different ways. Which one matches the user? The situation gets messier if then user is also building locally.
I can build the same version number in several different ways by switching branches as long as there are no uncommitted changes.
So our efforts to replicate the unique version numbers provided by SVN aren't working as expected.
Do we
- Kludge/fix the current revision numbers to restore uniqueness with respect to the generating code?
- Abandon a revision number and just use a git generated tag even thought it is a human unfriendly string?
- Understand that the revision number only has meaning for builds released on and downloaded from GitHub?
- Require users to reproduce incidents on the latest downloaded build if significant support is needed?
- ???
I admit to trying to apply a Configuration Management model that works real well with SVN to Git and that may be the problem. How would Git do it and should we talk about switching and managing expectations?