The automated step during a release that modifies the version string in project.clj is broken because it can't handle a version variable - it must be a hard-coded version string. The string literal was extracted into a variable because it needed to be referenced in multiple places in the file.
The release task has a step that changes the version property of the defproject map in project.clj. See the ["change" "version" "leiningen.release/bump-version" "release"] step here, and the corresponding source here.
This step expects the version to be a string literal in the defproject call, like so:
(defproject puppetlabs/puppet-server "1.1.0-SNAPSHOT" ...).
Instead of a string literal, we have pulled the string out into a top-level (def ps-version "1.1.0-SNAPSHOT") variable and use it like so: (defproject puppetlabs/puppet-server ps-version ...).
The "change" lein plugin cannot handle changing this top-level def - it can only change properties of the project map (that is, one of the :<property> values defined in the call to defproject).
There are several paths forward that would essentially solve this problem, or make it go away.
The first few attempt to improve support for changing variables/properties in the project.clj file:
- Improve the change plugin so it can modify top-level variables too, or write our own plugin that extends change
- Use a more general string find+replace plugin like lein-file-replace, though after some brief exploration I don't think this plugin would result in something maintanable
- Use a lower-level tool (i.e. sed/awk/something-on-the-OS) to perform the string find+replace, which could be shelled out to during release
Even better, we could try to eliminate the need for the top-level variable altogether so we can keep the version string literal in the call to defproject and not have to muck with lein plugins or shelling out. The other usage of the version string is in the ezbake profile dependency list here.
Wayne Warren is suggesting that we instead improve EZBake itself to not require this self-dependency, which as it just so happens would be a required step in making EZBake more usable outside of Puppet Labs anyway.
Risk assessment: Low (no additional validation required)
Probability: Low (does not impact users)
Severity: Low (does not impact users)