Although I don't have this problem yet, I hope to soon. How do modders manage their development versions without getting accidentally overwritten by the release version in PAMM? Are you just really careful with automatic updates, or do you have separate directories with modified module ids? On a related note, I'm thinking about adding some automation to clean up and package a mod for release. I'm probably going to have to have a separate id for development, and have the release process patch in the official one for testing and packaging.
I just overwrite the version of the mod already installed by PAMM with my in-dev version and then don't update it until I publish the update.
You don't really need to make it that complicated. PAMM won't auto-update your mods, and even if it did you could just increase the version number in modinfo.json before you start to work. If your mod ever got big enough to need separate test environments and a strongly controlled development process like that, you should probably think about splitting your mod into multiple smaller mods. When I was working on System Sharing, I realized that people needed a better way to see what was in the system. I started working on the fix in that mod, but then I moved it all into it's own separate mod because I realized it was doing its own thing that was really unrelated to the original mod. The result was a mod that works for systems in your own local library as well as shared ones. If your mods get too big to handle, just generalize some features and put them in their own mod. Maybe I misunderstand what you mean about packaging a mod and the whole release process thing, but it feels like you are either over-thinking the process or making a mod that does a little too much.
Main thing is considering using RequireJS optimizer to create a single file with the template built in, to avoid the async operation to load the template. I normally work from separate files during development, but I'll need to test the built version from time to time. Even now I've got a few files (formatted modinfo, .gitignore, entire .git directory...) that should not be packaged.
Doesn't really seem worth it unless you can get this done in an hour or two. It will probably be faster to just do things by hand. When you're talking about a job you aren't likely to still be doing the same way five years from now, the numbers go even more strongly against automation.
I use my super duper 7-zip command batch file Code: "C:\Program Files\7-Zip\7z.exe" a -xr!.* hotbuild2.zip hotbuild2 which makes me a perfect mod zip file without the .hidden . folders
PAMM won't update the mod until it detects a newer version in the repository, so that has never really been a problem, since the development version will never be older than the one in the repository. I do however increase the version number when I'm developping a mod further though, but that's just because otherwise I will invariably forget to do that for release. I did have one case of a mod being developed being overwritten by PAMM, but that was because @superouman used my sample skybox mod to create his own skybox mod, but kept the ID the same. Finally, put your mods on GitHub. You'll never loose them then.
which he didn't make himself ftm d-: lolz I update on a vm or another computer just to check if the update was deployed fine I never update through pamm on my main computer which holds the dev version.
I just structure them in a way that keeps all non mod stuff outside of the main "mod" directory. Like here: https://github.com/pamods/uimod-AlertsManager When I push an update I simply update the version numbers by hand in the pamm repos. However most of the updates I push are PA Stats and that is not versioned by pamm itself. For PA Stats I simply do a new release on github, download it from there and put the new files on my server, where I name the directory after the version. Then I replace a symlink so people get the version I want them to get.
I create a symbolic link from the mod directory to my mod's source code directory. I'm on Windows, so I create the symbolic link using Link Shell Extension. It works really well - I just need to press F5 inside the game to see the changes. I have a script for creating the release. It will automatically set the version number, release date and PA build in modinfo.json, create the relevant commits and tags, and package it all in a ZIP. Maybe later I'll also automate uploading it to PAMM. PAMM on Windows seems to check only the release date of the mod (using just a string equality comparison), so it won't notify about new versions to my mods, because I update the release date only when making a new release.
People use different versioning systems, and I didn't want to limit them to a fixed one in order to use that to determine if something was newer. The date seemed a simple way of doing it instead. Plus, this way you can push a downgrade if required.
It has the limitation that if somebody creates two releases in one day, then it won't notify about the second release if the first one is already installed. I think rBlueprintInfoFramework had exactly that situation yesterday - you had to read the forums to know that there was a new version and click reinstall.
I had that too at some point when I had to release a quick bugfix on the same day as the release. I kind of cheated and put the release date for the bugfix one day in the future. Although pamm for Linux/Mac does compare version numbers, it does get a bit iffy. It splits out the version into a list of strings using "." and "-" as separators. Then it tries to convert each individual string in the list to a number and if that fails, it compare the individual strings alphabetically. The comparison goes from left to right until a string is found to be different. It also knows that 1.1.1 is larger than 1.1 and such, but it's probably not hard to think of a case where this might fail. (Relevant code here) Anyway, both methods have drawbacks. The only proper solution would probably be to enforce a convention for version numbers, but I think that goes a bit too far.
Oh yeah right I have such a link, too. Plus I have 2 mods in pamm, one is a "dev version" so I can just switch from prod to test in pamm and start coding in eclipse.
