Support custom regex for x-release-please-* annotations in extra-files #2345
Description
Currently, the version updater in extra-files allows us to specify an inline line to update (with x-release-please-*
) or a block of lines (with x-release-please-start-*
).
However, within the block of lines it replaces any string that looks like a version number.
I have a fenced code block that provides sample code for installing my library (Google-maps-iOS-Utils) alongside a related dependency (GoogleMaps). I want release-please to update the dependency for my library without updating the version number of the other dependency.
When I try marking the code block, release-please updates every version number in the code block.
Input code
<!-- x-release-please-start-version -->
```ruby
use_frameworks!
target 'TARGET_NAME' do
pod 'GoogleMaps', '8.0.0'
pod 'Google-Maps-iOS-Utils', '4.2.2'
end
\```
<!-- x-release-please-end -->
Output (see automated commit in the Release PR)
use_frameworks!
target 'TARGET_NAME' do
pod 'GoogleMaps', '5.0.0'
pod 'Google-Maps-iOS-Utils', '5.0.0'
end
When I try marking the single line with an inline comment, release-please actually ignores that whole code block and updates other version numbers in other parts of the file.
Input code
use_frameworks!
target 'TARGET_NAME' do
pod 'GoogleMaps', '9.0.0'
pod 'Google-Maps-iOS-Utils', '5.0.0' # x-release-please-version
end
Output (see automated commit in the Release PR)
no change
use_frameworks!
target 'TARGET_NAME' do
pod 'GoogleMaps', '9.0.0'
pod 'Google-Maps-iOS-Utils', '5.0.0' # x-release-please-version
end
...
changed without any annotation
- github "googlemaps/google-maps-ios-utils" ~> 4.1.0
+ github "googlemaps/google-maps-ios-utils" ~> 6.0.0
Proposal
- Support more fine-grained definition of the string pattern to replace by accepting a regex parameter instead of the default regex pattern that looks for any major.minor.patch version number string. Perhaps something like the semantic-release-replace-plugin to accept a filename and a regex pattern. Example usage in a release config file before we migrated to release-please.
Alternatives
- Perhaps the second case (inline annotation within a code block) is behaving in an unexpected way due to a bug, and fixing the bug will satisfy my needs by supporting inline annotations within a code block.
- Support specifying a line number(s) instead of relying on code comment to identify which lines to search in.