You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am using this plugin to write the version into a plain text file, VERSION, as well as into composer.json and package.json. In the plain text file, the entire contents of the file is just the version number.
The VERSION file sometimes fails to update when release-it is run. I determined that this happens when the existing version (latest version) in the file is not the same as the latest version determined by release-it (e.g. from git tags — leaving aside how that might have happened):
$ cat VERSION
1.0.0
$ git describe --abbrev=0
1.0.1
$ npx release-it --increment=patch
*** releases version 1.0.2 ***
$ git describe --abbrev=0
1.0.2
$ cat VERSION
1.0.0
☝️ In this example, the latest tag is 1.0.1, but the VERSION file is out of date, showing 1.0.0. Running release-it creates a new tag, 1.0.2, but does not update VERSION to 1.0.2, instead leaving it as 1.0.0.
The reason is that the default file type operation for bumper is a search-and-replace method:
If the existing version string in the file does not match the latest version (as determined from, e.g. git tags), then no replacement is made. This was unexpected to me, and is counter-intuitive, given that this is not the behaviour for structured file types such as JSON — there, the field is always updated, because bumper is able to determine where to write the updated version string without having to search for the previous one. So e.g., in the above toy example, composer.json and package.json could show the same existing version 1.0.0 as VERSION, yet they would be modified to show 1.0.2 by bumper.
A closer reading of the README.md does say (emphasis added):
To replace all occurences of the current version with the new version in any text file:
N.b. just realised a workaround is not to use bumper at all for this use case 🤦 , a simple hook in release-it would achieve the expected result, regardless of existing file contents:
Nonetheless, if you're using bumper to write to other files anyway, it might be nice to keep everything together in the bumper ecosystem. PR #32 implements a suggested solution.
I am using this plugin to write the version into a plain text file,
VERSION
, as well as intocomposer.json
andpackage.json
. In the plain text file, the entire contents of the file is just the version number.The
VERSION
file sometimes fails to update when release-it is run. I determined that this happens when the existing version (latest version) in the file is not the same as the latest version determined by release-it (e.g. from git tags — leaving aside how that might have happened):☝️ In this example, the latest tag is
1.0.1
, but theVERSION
file is out of date, showing1.0.0
. Running release-it creates a new tag,1.0.2
, but does not updateVERSION
to1.0.2
, instead leaving it as1.0.0
.The reason is that the default file type operation for bumper is a search-and-replace method:
bumper/index.js
Lines 142 to 145 in 7a53a90
If the existing version string in the file does not match the latest version (as determined from, e.g. git tags), then no replacement is made. This was unexpected to me, and is counter-intuitive, given that this is not the behaviour for structured file types such as JSON — there, the field is always updated, because bumper is able to determine where to write the updated version string without having to search for the previous one. So e.g., in the above toy example,
composer.json
andpackage.json
could show the same existing version1.0.0
asVERSION
, yet they would be modified to show1.0.2
by bumper.A closer reading of the README.md does say (emphasis added):
but this could probably be clearer.
N.b. this could become more of a problem, since release-it 16.1.0 added a new feature to determine the latest version from git tags across all branches. In such situations, it is more probable that a plain text file like
VERSION
would be out of sync with that.The text was updated successfully, but these errors were encountered: