I am wondering whether I should branch our installer script/project-file (we use InnoSetup) with each application release or whether I should keep one in installer script that generates the setup for all versions and branches.
We use branches ("maintenance versions") heavily as our features are very customer driven and we often first implement a bugfix in a specific customer version to keep things stable. (Yes. Not optimal. But it's also what the customers like. As little code-changes as possible to take no risk with their expensive hardware lying idle because of regressions.)
So our branches/versions would look like this
v150.6 - "150" branch installed with customer X v151.7 - "151" branch installed with customer Y, Z, A and B ... v156.3 - "156" branch installed with customer C and D vCurrent - Development of new features - will produce a v157 eventually
I have now checked in our setup script into version control and it already has seen quite a few bugfixes and tweaks.
At the moment, when a new v151.n+1 maintenance version is built, the automated build scripts take the setup script checked into v151 branch and create a setup with this. So obviously, a v151.8 version would have a bit an outdated installer, although "95%" of all fixes to the installer would be applicable to all old releases.
I am therefore considering adjusting our automated build scripts to always use the setup script from the vCurrent branch: - also for the setups of newly created maintenance versions of old branches.
What is your take on this. Should a setup/installer script be "tightly bound" to a sourcecode version, or should the lifecycle of setup logic be more independent from the actual code-version/binaries being installed, so that fixes to the setup logic can be used across a range of different (maintenance) versions?