I am just getting started on a new module PSGraphPlus and if you know me, this is when I take a look at how I build modules. I fleshed out a lot of little bugs with my Full Module Plaster Template and I spent a little time working on my module build script. I may talk about that build process in another post but for the sake of this conversation, it is just a script that I run that performs several actions on my module. It runs tests, bumps the version and publishes to the PSGallery.
Today, I am going to walk you through how I bump that version based on changes in my module.
What is a Semantic version number?
This is greatly simplified but will cover what we need for today. Check out semver.org if you would like more information.
I leverage the BuildHelper community module to help me update the version on my manifest. It has a lot of great little tools in there. We are going to work with Step-ModuleVersion today.
If we want to bump it from 2.13.87 to 2.13.88, we can use Step-ModuleVersion to do so.
That command makes it easy to bump the version every time, but I want Semantic versioning.
I decided to monitor the function names and their parameters to detect breaking changes. My theory is that if I ever remove or rename a function or its parameter, I should consider that a breaking change and update the major version number. I can use that same logic to detect the addition of functions or parameters as a feature addition.
Here is the code that does that.
We will then save that fingerprint to a file in the project.
Each build we will load the existing fingerprint, compare it to the current one and update it. Comparing each line between the two fingerprints will let us know if we added or deleted something.
In this example, if there were no changes then we would bump the Patch version. If I have something in the new fingerprint that is not in the old one, then we bump the Minor version. Finally, we move onto detecting when a fingerprint that was there before but was removed in order to bump the Major version.
Now that we know what to bump, we return to Step-ModuleVersion to take care of it.
Having this as part of my module build script will allow me to automatically indicate if a release has a breaking change. This only does so much. I can still update my version by hand when needed if there are other changes that would not be detected by this.
The one issue with this approach is the extra file added to the project. This means that if you use a build system to run this, you would have to have it check the file in after the build. I currently run it locally so the fingerprint becomes part of my check-in.
I had an earlier version of this that would use the FunctionsToExport in the module manifest to detect changes. It only handled new and removed functions.
I'll see how it works on this project before I go add it to all my other projects. If you want to see this in my build script, you can see it here: module.build.ps1.