Standard or recommended approach to developing a module or extension with sensible version control / git

Last year I authored an extension with custom Java code, and in doing so I made sure I was version controlling that source code (with git). This is the repo:

rummelsworth/vassal-pzb-deluxe (github.com)

I was wondering:

(a) if there is an existing recommendation on how to elegantly and version-controlledly (cool word! yay me) develop modules or extensions, even when they don’t require custom code and are only operating on the XML that’s zipped into the VMOD/VMDX file; and

(b) if there isn’t, could an elegant and simple accommodation of such an approach be part of Vassal’s roadmap?

Hmm… Where is the roadmap? Maybe I’m echoing something already there.

I’m about to embark on my first VMOD, and so will for now probably continue to use my somewhat manual approach described at my repo linked above. I could probably add a couple scripts to make it easier.

1 Like

I suggest putting the module contents in version control. That is, check in what you get when you unzip the module.

1 Like

Sounds good, will continue that way.

Yeah my slightly-more-elaborate take on what Joel says above is:

  1. I make a folder where I want to keep my work
  2. I initialize a “git” repository in that folder. In my case I also attach that repo to one on github.com.
  3. I unzip the contents of my module into that folder (and subfolders)
  4. I do a git add * and then git commit -m "First Commit" or some such

Meanwhile I make a couple little batch files (I’m on Windows; you’d use bash scripts or whatever anywhere else), to create the commands “build” and “push” and “pull” or whatever for me using 7Zip.

Examples of my scripts for my Almoravid module:

  1. build.bat (zips the directory structure into a vmod file)
del .\Almoravid_%1.vmod
del .\Almoravid_%1_es.vmod

# a = add to archive
# -mx1 = fastest compression
# -tzip = zip archive format

7z a Almoravid_%1.vmod *.xml -mx1 -tzip
7z a Almoravid_%1.vmod *.pdf -mx1 -tzip
7z a Almoravid_%1.vmod HowToPlay.html -mx1 -tzip
7z a Almoravid_%1.vmod changelist.html -mx1 -tzip
7z a Almoravid_%1.vmod notes.html -mx1 -tzip
7z a Almoravid_%1.vmod updatingmodule.html -mx1 -tzip
7z a Almoravid_%1.vmod *.vsav -mx1 -tzip
7z a Almoravid_%1.vmod moduledata -mx1 -tzip
7z a Almoravid_%1.vmod Module_es.properties -mx1 -tzip
7z a Almoravid_%1.vmod help\ -r -mx1 -tzip
7z a Almoravid_%1.vmod help_es\ -r -mx1 -tzip
7z a Almoravid_%1.vmod images\ -r -mx1 -tzip
7z a Almoravid_%1.vmod images_es\ -r -mx1 -tzip
7z a Almoravid_%1.vmod help_es\ -r -mx1 -tzip
7z a Almoravid_%1.vmod Almoravid\ -r -mx1 -tzip
  1. pull.bat - pulls only the buildfile from the module (useful when I make simple changes in the editor but I haven’t added any new files or whatever. The exotic directory name is just where I happen to keep the module)
7z x "C:\Users\Brian Reynolds\Documents\Gaming & German Game Rules\Vassal\Almoravid_%1.vmod" buildfile.xml -aoa
7z x "C:\Users\Brian Reynolds\Documents\Gaming & German Game Rules\Vassal\Almoravid_%1.vmod" moduledata -aoa
  1. pullall.bat - pulls everything from the current vmod file
7z x "C:\Users\Brian Reynolds\Documents\Gaming & German Game Rules\Vassal\Almoravid_%1.vmod" * -aoa

So my workflow then becomes…
(1) Make changes to my module in the editor
(2) Save the changes in the editor
(3) Run “pull” or “pullall” to pull the changed files into my directory structure
(4) Run git commands to add/commit/push things in my project
(5) Lather, rinse, repeat.

If I ever need to revert to an earlier version from source control, I could do something like
(1) git checkout SomeOtherVersion
(2) run “build” to take what’s in the directory structure and assemble it into a working module.

Hope that helps!

Brian

4 Likes

Excellent, I think the “build”/“pull” script-pair is the sauce I was missing. Once I’ve automated those operations similarly, I’ll have a perfectly adequate setup.

Thank you both!

–William

1 Like

Well, I finished my first Vassal module. Took me about three hours start to finish, then it took me about six hours to fiddle with my scripts to get them “just right”… I borrowed the build/pull idea (from above) and re-termed it build/unbuild for my script names, to avoid any of my own cognitive dissonance versus the concept of “pull” in git. I didn’t try to allow selective pull because my module is so small. I used PowerShell Core instead of batch/7-zip to allow slightly easier development setup.

If anyone’s interested in the PowerShell Core scripts, they’re at my module’s repo:

rummelsworth/vassal-module-kassala (github.com)

Again, thank you @Cattlesquat for inspiring the scripts. What a slick feeling to run them and see all that magic happen automatically…

1 Like

Random thought: it might be nice if there was a GitHub Action that would run to automatically create the .vmod/.zip file on check in. If someone had one of those and posted it here, it would be easy for others to copy it and modify it for their own use.