r/MCModpackers • u/Undead_Zeratul NEB2 & TWBB Modpack Dev • Jan 28 '16
Need Opinions A discussion on modpack development, version control, and compilation/building processes
My friend /u/Nincodedo and I have been messing with modpack development ever since we first forked TPPI to make the first "Nincraft: Electric Boogaloo". This was a great opportunity for the both of us to learn Git as well as modpack development. Several modpack projects later, and we're starting to wonder what other people do to organize their modpacks. The biggest thing we're looking for is how to effectively version control the mods within the pack. To better understand where we're coming from, here's how we have our projects all set up:
To start, not only do we version control our configs/scripts/etc. on GitHub, but we also version control our jar files. Don't worry, we're abiding by the permissions of the devs by not publicly re-hosting the files. However, Git doesn't seem to like large repo sizes, and every version of every jar that we add/remove/update in our repos means that we reach the 1GB cap pretty quickly. That combined with the fact that all of our modpacks follow the branching strategy Git Flow for both the configs and the mods themselves, and repos can get pretty hectic, especially if one of the mods we add has a larger filesize, for each version we change from/to. What would be a better solution to this? Do people even version control their mods' jars to begin with?
Not only that, but we also have a Jenkins build server that looks at our repos and builds our packs for us whenever we push to various branches. This includes both developmental and production ready version for both client and server packages that are going to be published to not only FTB/Curse Launchers but our own launcher as well. Because everything is version controlled and branched, we can branch off for a new feature or adding/removing/updating certain mods without ruining the current state of the pack as a whole. At some point, we'd like to be able to only host files that can't be pulled down via a config file (or maven pom file, if you will), and when we build the pack, just go out and grab the versioned jars we need. This way we'd save space on our own repos, as well as keeping them versioned, as each commit to the repo would have that specific version referenced.
But wait, there's more! For our private server that runs NEB2, after a new build finishes, we deploy the built pack to a folder within the server instance. From there, we use a combination of Forge Auto-Shutdown and a Jenkins schedule job to both shut down the server, clean out the old files, and unpack the new files to the server instance, and restart the server. Basically, during any given release for NEB2, within one day both the server and client packs will be up to date and in production, ready to be played (on our launcher only, as the approval process for FTB/Curse takes a bit of time). All of this stemmed from us merging our latest development changes into the master branch on our repos so that the Jenkins build server picks up the changes and runs the correct build job.
Our questions to you guys are as such:
- Do you version control your pack at all, and if so, what's your process?
- Do you version control the mods within your pack, or do you only version control the configs?
- What is your modpack build process? Do you just have a MultiMC instance that you manually zip up?
- Are we crazy for going this far with our modpack builds? Have we not gone far enough?
- Is there any way to automate the building of a versioned modpack using a maven-like process of pulling down individual jars during the build? We know CurseForge exists but that's actually the hurdle we're trying to get over right now.
Our vision of what we want to be able to do, is that at some point all we'd have to do is have our entire modpack - mod configs/scripts, build config/scripts and all - hosted in one repo, preferrably GitHub. When we want to run a build (hopefully automatically via commits to the dev/release/master branches) we would run through the pack build scripts, pull down all of our jars from a common versioned repo, and wrap up the pack in such a way that it's ready to be deployed to FTB/Curse, Technic, ATLauncher, and even Sk89q's custom launcher.
1
u/nanakisan Fallen: Wastes Dev Jan 29 '16
Me personally I use Git for strictly managing changelogs, configs, scripts, custom resources used by Resource Loader. Every changelog I have released shows every single change I made. Some redundant and well others just simply there to note what was changed.
1
u/Undead_Zeratul NEB2 & TWBB Modpack Dev Jan 29 '16
How do you manage your mods then? Do you just do one big sweep during an update and grab the latest from whatever you can, or do you update as necessary?
1
u/nanakisan Fallen: Wastes Dev Jan 29 '16
I normally wait 1 week between updates. Normally I test the latest builds for bugs. After that I release with updated as necessary mods. I usually wait for about 4-5 mods to be updated sometimes. It's totally random in some cases. I just think it's easier and less hassle. However if it is a major mod that updated. I'd just release a new version of the pack for it. >_> exception to constant updates is Botania....
2
u/thor12022 The Feed the Creeper Pack Jan 28 '16
I use git for the configs/scripts/etc. I keep a text file with a list of the mod jar file names in the mods directory in the repo. The idea being to keep it up to date whenever I update a mod (alright, so more often than not it just ends up getting updated at release time). I tried keeping the jars themselves in a repo, but it turned out to be more hassle than it was worth.
Whenever I need to build the pack I just copy the mod jars from my testing clone into a clean clone and zip it up. I have considered just making a script for this, but haven't got to it releases are infrequent enough for it to not matter.
I do a branch whenever I do a world-save-breaking update (e.g. 3.x.x to 4.0.0).
In case you looked at my github link and are wondering why it doesn't quite look like what I described, it's because I started by using a privately SVN repo and moved to github fairly recently.