First of all, thank you for creating and maintaining release-please. I am not sure if this is a bug or intended behavior, so I decided to create this as a feature request.
Is your feature request related to a problem? Please describe.
I am building a wrapper project over a native C library. My library has its own version X.Y.Z. But to communicate to consumers which version of the native library this release wraps, I want to use SemVer 2.0 build metadata for that: X.Y.Z+native.A.B.B.
Each library version is supposed to be unique, and the build metadata is only informational!
Projects for reference:
When I bump the library version, I manually edit the .release-please-manifest.json to the new build version. To ensure I always have a unique semantic version, I have configured deps to increment the minor release.
My git log might look like this:
tag v1.2.2+native.A.B.C
fix: Some fix in my lib
tag v1.2.3+native.A.B.C
feat: Some feature in my lib
deps: Update the native lib to A.B.D
-> When I now want to release my lib, release-please will try to find an old tag matching the pattern vX.Y.Z+native.A.B.D, which, of course, it does not find. Therefore, it falls back to including all previous commits in my changelog.
Describe the solution you'd like
Release-please should ignore the build metadata completely when inferring the previous tag.
Please note that I am not asking for release-please to edit the build metadata. Right now, release-please is already able to ignore the build metadata when updating, and I can only adjust the library version.
Without being in the details, I would say that the problematic comparisons are here and here and probably should ignore the build metadata.
Describe alternatives you've considered
- Right now, when releasing, I always temporarily create a new tag
oldLibraryVersion+newNativeVersion so release-please is able to find a matching tag. After the release is done, I remove that tag again.
- Do not use build metadata to communicate the native version (would be unfortunate, of course xD)
Additional context
Note: I tested this with 17.3.0. But as far as I can see, there were no changes up to 17.10.0 which would affect tag matching.
Example run without a tag with matching build metadata:
Running release-please version: 17.3.0
❯ Fetching .release-please-config.json from branch main
❯ Fetching .release-please-manifest.json from branch main
✔ Building releases
✔ Building strategies by path
❯ .: simple
❯ Fetching .release-please-config.json from branch main
❯ Fetching .release-please-manifest.json from branch main
✔ Building pull requests
✔ Building strategies by path
❯ .: simple
✔ Collecting release commit SHAs
❯ release search depth: 400
❯ Fetching releases with cursor undefined
⚠ Expected 1 releases, only found 0
⚠ Missing 1 paths: .
⚠ Expected 1 releases, only found 0
❯ looking for tagName: v0.4.1+luau.0.726
✔ Collecting commits since all latest releases
❯ commit search depth: 500
❯ Set(0) {}
❯ Fetching merge commits on branch main with cursor: undefined
❯ Backfilling file list for commit: 0e6fe34234ec1fabe8a8f25d5d86c443f34386ee
❯ Found 1 files
❯ Backfilling file list for commit: aab31cdb809cf66b4f6ad3a68132ae09c0b1116c
❯ Found 1 files
❯ Backfilling file list for commit: d2ed0e6c62ce7f433680703cf8d8cc7df81c8121
❯ Found 2 files
❯ Backfilling file list for commit: 0990c2a126490f359a7ab4c0c104a7653b41ed38
❯ Found 1 files
❯ Backfilling file list for commit: 48d0163bc95736914e957cf6e85e9b03c44f330c
❯ Found 2 files
❯ Fetching merge commits on branch main with cursor: 42da4cd225f5183ebae66a4cc1ea0fbc61e7a188 9
❯ Backfilling file list for commit: ec2eac990a1e8c1dfc93a2ecacda4a71264480c5
❯ Found 9 files
❯ Backfilling file list for commit: 322013f564773fef3f0c331df8b99505d70720cd
❯ Found 4 files
❯ Backfilling file list for commit: 07aed471bea27ab10b8f647dfb37869c86cc53c7
❯ Found 1 files
❯ Backfilling file list for commit: 4d7aaad62db63d9fd1a91b15382ac01125ebd311
❯ Found 2 files
❯ Backfilling file list for commit: 249857a5501f902071c3ee8a6218b06d10704950
❯ Found 1 files
❯ Fetching merge commits on branch main with cursor: 42da4cd225f5183ebae66a4cc1ea0fbc61e7a188 19
❯ Backfilling file list for commit: 8aab1090e42a04b867e6a7f8d479459d94dc0106
❯ Found 3 files
❯ Backfilling file list for commit: b4168743262f8804a649d3b8cffa458f8ffc22de
❯ Found 1 files
❯ Backfilling file list for commit: 41be5b8c553dfc790e768c01420b67c970516e2d
❯ Found 1 files
❯ Backfilling file list for commit: 071c85324ebf7dea869af79fa91910927d32da97
❯ Found 7 files
❯ Backfilling file list for commit: 6de65f9fd3c8475d4b7e8f1e32a2273dbb0934ed
❯ Found 1 files
❯ Backfilling file list for commit: 0f163727d38ad72dc18a9ec0aebf586d592cc2ce
❯ Found 2 files
❯ Backfilling file list for commit: 64b3acbe59b264bd9c481d87784e7a9f9dfacaaf
❯ Found 1 files
❯ Backfilling file list for commit: 5df27c320a57c6ce95e240e376adb5e138c528b3
❯ Found 1 files
❯ Backfilling file list for commit: 3e5a83f937f3954b75f0b48eef411df5ae628223
❯ Found 1 files
❯ Backfilling file list for commit: 24275890069ad7f366647922b3d1b145fdad8285
❯ Found 3 files
❯ Fetching merge commits on branch main with cursor: 42da4cd225f5183ebae66a4cc1ea0fbc61e7a188 29
❯ Backfilling file list for commit: 1b16effc2bec7cc03f40a256ec40dc11780c06a6
❯ Found 1 files
❯ Backfilling file list for commit: 3685070e99adc60fe3544803d1b9169d98072fe9
❯ Found 3 files
❯ Backfilling file list for commit: 9cd715c79b21ce7d93b2b4933004c8c9ff120c80
❯ Found 2 files
❯ Backfilling file list for commit: ee266e65eff5d75c765339787b71769f81d6e961
❯ Found 1 files
❯ Backfilling file list for commit: 1b8a78f6ab527d4385fdd2d3dbc19d46d6acee21
❯ Found 6 files
❯ Backfilling file list for commit: e8667511bf94c693af80d3c8976e3daf5ed2806f
❯ Found 7 files
❯ Backfilling file list for commit: 2ee85b5994df60333646d11e835cc6a360a8779a
❯ Found 5 files
❯ Backfilling file list for commit: 2307005c78c0a5fd7145b93092c08c8bd007ecd9
❯ Found 23 files
✔ Splitting 38 commits by path
✔ No latest release found for path: ., component: , but a previous version (0.4.1+luau.0.726) was specified in the manifest.
✔ Building candidate release pull request for path: .
❯ type: simple
❯ targetBranch: main
❯ commit could not be parsed: 1400f8c717a5b3d91bd9823165fea7471e71721e Merge pull request #1 from rosslight/release-please--branches--main--components--Darp.Luau.Native
❯ error message: Error: unexpected token ' ' at 1:6, valid tokens [(, !, :]
⚠ No latest release pull request found.
❯ commits: 42
✔ Considering: 42 commits
❯ component:
❯ pull request title pattern: undefined
❯ componentNoSpace: undefined
✔ Looking for open release pull requests
✔ found 1 open release pull requests.
✔ Looking for snoozed release pull requests
✔ found 0 snoozed release pull requests.
❯ Fetching CHANGELOG.md from branch main
❯ Fetching version.txt from branch main
⚠ file version.txt did not exist
❯ Fetching Directory.Build.props from branch main
❯ Fetching .release-please-manifest.json from branch main
✔ Starting GitHub PR workflow...
✔ Successfully found branch HEAD sha "42da4cd225f5183ebae66a4cc1ea0fbc61e7a188".
✔ Skipping branch creation step...
✔ Got the latest commit tree
✔ Successfully created a tree with the desired changes with SHA 230e76e530aa4b12b1bc50ae71936ed328773d4d
An example run after I manually created a tag with matching build-metadata:
Running release-please version: 17.3.0
❯ Fetching .release-please-config.json from branch main
❯ Fetching .release-please-manifest.json from branch main
✔ Building releases
✔ Building strategies by path
❯ .: simple
❯ Fetching .release-please-config.json from branch main
❯ Fetching .release-please-manifest.json from branch main
✔ Building pull requests
✔ Building strategies by path
❯ .: simple
✔ Collecting release commit SHAs
❯ release search depth: 400
❯ Fetching releases with cursor undefined
⚠ Expected 1 releases, only found 0
⚠ Missing 1 paths: .
❯ looking for tagName: v0.4.1+luau.0.726
❯ found: v0.4.1+luau.0.726 057379dfdb084f33751359d715fdeb48423141f1
❯ release for path: ., version: 0.4.1+luau.0.726, sha: 057379dfdb084f33751359d715fdeb48423141f1
✔ Collecting commits since all latest releases
❯ commit search depth: 500
❯ Set(1) { '057379dfdb084f33751359d715fdeb48423141f1' }
❯ Fetching merge commits on branch main with cursor: undefined
❯ Backfilling file list for commit: 0e6fe34234ec1fabe8a8f25d5d86c443f34386ee
❯ Found 1 files
❯ Backfilling file list for commit: aab31cdb809cf66b4f6ad3a68132ae09c0b1116c
❯ Found 1 files
❯ Backfilling file list for commit: d2ed0e6c62ce7f433680703cf8d8cc7df81c8121
❯ Found 2 files
❯ Backfilling file list for commit: 0990c2a126490f359a7ab4c0c104a7653b41ed38
❯ Found 1 files
❯ Backfilling file list for commit: 48d0163bc95736914e957cf6e85e9b03c44f330c
❯ Found 2 files
✔ Splitting 3 commits by path
✔ Building candidate release pull request for path: .
❯ type: simple
❯ targetBranch: main
❯ commits: 3
✔ Considering: 3 commits
❯ component:
❯ pull request title pattern: undefined
❯ componentNoSpace: undefined
✔ Looking for open release pull requests
✔ found 1 open release pull requests.
✔ Looking for snoozed release pull requests
✔ found 0 snoozed release pull requests.
❯ Fetching CHANGELOG.md from branch main
❯ Fetching version.txt from branch main
⚠ file version.txt did not exist
❯ Fetching Directory.Build.props from branch main
❯ Fetching .release-please-manifest.json from branch main
✔ Starting GitHub PR workflow...
✔ Successfully found branch HEAD sha "42da4cd225f5183ebae66a4cc1ea0fbc61e7a188".
✔ Skipping branch creation step...
✔ Got the latest commit tree
✔ Successfully created a tree with the desired changes with SHA bfde4040905dde8cdd0c1845f543ac26b938d8e9
First of all, thank you for creating and maintaining release-please. I am not sure if this is a bug or intended behavior, so I decided to create this as a feature request.
Is your feature request related to a problem? Please describe.
I am building a wrapper project over a native C library. My library has its own version
X.Y.Z. But to communicate to consumers which version of the native library this release wraps, I want to use SemVer 2.0 build metadata for that:X.Y.Z+native.A.B.B.Each library version is supposed to be unique, and the build metadata is only informational!
Projects for reference:
When I bump the library version, I manually edit the
.release-please-manifest.jsonto the new build version. To ensure I always have a unique semantic version, I have configureddepsto increment the minor release.My git log might look like this:
tag v1.2.2+native.A.B.C
fix: Some fix in my lib
tag v1.2.3+native.A.B.C
feat: Some feature in my lib
deps: Update the native lib to A.B.D
-> When I now want to release my lib, release-please will try to find an old tag matching the pattern
vX.Y.Z+native.A.B.D, which, of course, it does not find. Therefore, it falls back to including all previous commits in my changelog.Describe the solution you'd like
Release-please should ignore the build metadata completely when inferring the previous tag.
Please note that I am not asking for release-please to edit the build metadata. Right now, release-please is already able to ignore the build metadata when updating, and I can only adjust the library version.
Without being in the details, I would say that the problematic comparisons are here and here and probably should ignore the build metadata.
Describe alternatives you've considered
oldLibraryVersion+newNativeVersionso release-please is able to find a matching tag. After the release is done, I remove that tag again.Additional context
Note: I tested this with 17.3.0. But as far as I can see, there were no changes up to 17.10.0 which would affect tag matching.
Example run without a tag with matching build metadata:
An example run after I manually created a tag with matching build-metadata: