conventional-changelog-conventionalcommits v8.0.0 breaks semantic release #633
Comments
|
I had the error even with |
I'm not sure what that means. I simply have a |
|
@ryancausey Oh, I'm not sure, I'm configuring all the plugins explicitly, and the plugins accept the |
Seems like there is a bug with semantic-release plugins conflicting with latest major conventional commits. Reverting as issue suggests: semantic-release/release-notes-generator#633 commit-id:b1f4a00c
Seems like there is a bug with semantic-release plugins conflicting with latest major conventional commits. Reverting as issue suggests: semantic-release/release-notes-generator#633 commit-id:b1f4a00c
|
the conventional-changelog packages released new major versions. that means they include breaking changes. since they were just released, no work has been done to make adjustments to account for the changes in semantic-release. if someone would be willing to investigate what changes would be needed, that could help us adjust for these changes sooner |
|
@travi yeah that makes sense. If we need to customize the preset though, we have to install it, and then it's easy to install the wrong version... so should we make this package check the version of the preset at runtime, and at least print a warning? I would almost suggest we put the compatible version in |
I understand the desire, but npm doesn't provide a great way to define these sorts of relationships. I'm open to proposals as a separate issue if there are options that I'm not aware of, but this is a difficult one to solve. I think the closest might be peerDependencies with meta defining the optional part, but I think there are complexities that make that not ideal too |
|
For folks landing here for various breakages related to updating conventional-commits packages before semantic-release is updated to handle the breaking changes, I'm trying to consolidate the conversation in this thread. Until I get more organized about that, please see my suggestions in semantic-release/semantic-release#3292 (comment) |
|
@travi not sure you saw my suggestion to check and warn at runtime if the preset package being used is not a known compatible version, would you be okay with a PR to do that? |
sorry. i did, but forgot to comment about that approach. it doesnt seem to me like there is a clean approach there either that is maintainable and still accomplishes the goal for new breaking changes. our approach to true peer dependencies and node versions is to keep them open ended, so we would have to release a new version with updated ranges once we are aware that a new major version is incompatible, which also requires responding fairly quickly to be most helpful. each of the conventional-commits packages has its own individual major version (an approach that i agree with), so we would have to handle each one individually. this also means more investigation when trying to release a version for such incompatibility communication. in the end, i think this almost entirely comes down to folks installing latest versions in pipelines without pinning a major version. would be open to suggestions to make this suggestion more clear and discoverable in docs or elsewhere in a general way that doesnt require maintainer action each time that breaking changes are released in conventional-commits packages. |
In my case it wasn't that - I was installing I can understand where you're coming from though. I can also understand the way all these different packages are structured. But - figuring out how to even customize everything and follow the control flow of release notes generation has left me thinking the work of fetching and parsing git commits and generating a changelog from them is spread out across too many packages for its own good. Maybe I would feel differently if these were all TS projects or the configuration was done via a strongly typed TS API rather than an unvalidated JSON DSL. It's pretty hairy to dig into how the configuration is getting passed around and used. And at least half of the code is for implementing that DSL that isn't really capable of doing what I want anyway, I wish I could just provide a function for filtering and categorizing commits by type and scope, etc, which would be way more flexible and require way less library code. |
|
We have the same issue.. |
I agree that is what people should do. However, the problem I found is that is currently hard to test if a major version bump will cause something to fail as we have semantic-release only running on our main branch. Implementing semantic-release/semantic-release#3278 would allow us to at least run with dry-run in a branch where we upgrade versions and see if anything breaks |
We can't yet rely on the SemVer tool semantic-release/release-notes-generator#633 (comment)
|
@ashvardanian the new beta of semantic-release is intended to work with the latest majors of conventional-changelog presets. As mentioned in the release notes, that means older version will no longer work. For the eslint preset, it looks like v6.0.0 is the latest version, but you're project is still configured to use v3. |
|
So what is the plan? |
|
I just asked myself that. currently my Semantic release is no longer running. my gitlab ci pipelines are standing still. |
|
There are two options available
|
|
Hi @travi! Thanks for suggestions! I've bumped all the versions in my {
"name": "simsimd-ci",
"version": "1.0.0",
"devDependencies": {
"@semantic-release/exec": "^6.0.3",
"@semantic-release/git": "^10.0.1",
"@semantic-release/commit-analyzer": "^12.0.0",
"@semantic-release/release-notes-generator": "^13.0.0",
"@semantic-release/github": "^10.0.5",
"conventional-changelog-eslint": "^6.0.0",
"semantic-release": "^24.0.0-beta.2"
},
"release": {
"debug": true,
"ci": false,
"dryRun": false,
"private": true,
"branches": [
"main"
],
"plugins": [Then, when I run the following command locally: npx --prefix .github/workflows semantic-release --no-ci --no-npm --debugI'm still getting errors like: Same happens if I remove any GitHub-related dependencies or steps. How can I "dry-run" the semantic release pipeline locally to avoid polluting the release history and the |
|
You do not need to/should not install the commit-analyzer or release-notes-generator plugins as direct dependencies, since they are already dependencies of semantic-release itself. If you test with |
|
@travi, I've just tried that locally and still face same issues. What else would you recommend trying? |
I've tested with this and it resolved my issue. |
|
Would be nice if this was something that wasn't always discovered aftter an update was being made in a repo. |
Fixes the breakage from the latest commit analyzer release. Refs: semantic-release/release-notes-generator#633
A command like |
Fixes the breakage from the latest commit analyzer release. Refs: semantic-release/release-notes-generator#633
A. Create and securely store a GitHub Personal Access Token that has |
|
FYI, tried on self-hosted gitlab with python project and it works as expected. 🎉 script:
- npm install @semantic-release/gitlab @semantic-release/exec @semantic-release/changelog conventional-changelog-conventionalcommits @semantic-release/git -D
- npx [email protected]configuration of plugins:
- "@semantic-release/commit-analyzer"
- "@semantic-release/release-notes-generator"
- - "@semantic-release/changelog"
- changelogFile: CHANGELOG.md
- - "@semantic-release/git"
- assets:
- CHANGELOG.md
- - "@semantic-release/exec"
- prepareCmd: "poetry version ${nextRelease.version} && poetry build"
- - "@semantic-release/gitlab"
- assets:
- path: "dist/*.whl"
type: "package"
- path: "dist/*.gz"
type: "package"
- path: "CHANGELOG.md"
type: "runbook"
preset: "conventionalcommits" |
|
🎉 This issue has been resolved in version 14.0.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
|
Thank you @sherbakovdev for contributing to getting this out the door and to @ryancausey and @imliuruiqi for testing out the fix and confirming that it solved the problem in your projects 🎉 |
* Improve: Swift test for issue #399 (#400) * Fix: Integer overflow in aligned-alloc Fixes ClickHouse/ClickHouse#61780 Co-authored-by: Antonio Andelic <[email protected]> * Make: Disable Windows NPM builds Relates to the #377 and the comment: #377 (comment) This temporarily disables the failing CI pipeline to generate and update docs. * Fix: Going beyond level 0 in clustering * Improve: Error handling in `index_dense_gt` This commit drops `std::vector` dependency, making compilation time shorter and error handling universal across abstraction layers. * Improve: Remove `std::function` calls * Improve: Remove `std::thread` from `index_dense_gt` * Improve: `std::vector` -> `buffer_gt` in plugins * Add: `usearch_change_threads_search` * Fix: `index_dense_t::make(path)` * Fix: Exhastive Search In the past, if we got "too lucky" traversing the graph, we could exit early before accumulating K top matches, even if the index had more than K entries. This patch changes that behavior, making output more predicatable. * Fix: Replacement leaves isolated nodes This patch addresses the issue #399, originally observed in the Swift layer. Reimplementing it in C++ helped locate the issue and lead to refactoring the `update` procedure in the lowest-layer `index_gt`. Now, `add` and `update` share less code. The `add` is one branch shorter (not that it would be noticeable), and `update` brings additional logic to avoid spilling `updated_slot` into top-results and consequently introducing self-loops. Closes #399 * Fix: Misc warnings & compilation issues * Fix: Misc warnings & compilation issues * Fix: Detect `ring_gt` being full Relates to #355 * Fix: Re-init `available_threads_` after load Both `view` and `load` would `reset` the thread contexts. After that, the very first `search` and `add` would fail, as no thread-local contexts are initialized. It would require a `reserve` call with a non-zero second arcgument to define the number of concurrent threads, for which the queues & buffers need to be allocated. That design is counter-intuitive, so this patch re-inits the same number of threads as before the `load` & `view` or one, if none existed. * Fix: `uint32_t` to `uint40_t` cast (#404) Co-authored-by: Ash Vardanian <[email protected]> * Docs: Mention `b1` in `README.md` Co-authored-by: Adolfo Garcia <[email protected]> * Docs: Cover new users * Improve: Updates stability & catch bug * Fix: Dereferencing `member_iterator_t` * Add: Java `get` API (#407) * Fix: Compilation with `uint40_t` keys * Add: `AutoClosable` using `c_destroy` for Java (#408) * Fix: Rare deadlock on tiny collections * Improve: `enable_key_lookups=false` memory usage As noted by Robert Schulze, we can avoid populating `slot_lookup_` during insertions, if `enable_key_lookups` is not set. This would lead to lower memory consumption for large indexes of tiny vectors, particularly common in GIS. Co-authored-by: Robert Schulze <[email protected]> * Fix: Preset `enable_key_lookups=true` in C * Fix: `std::is_pod` deprecated in C++20 * Fix: Unused type aliases * Improve: Avoid `#pragma region` pre GCC 13 (#386) * Do not use #pragma region if not supported by the compiler * `pragma region` supported by GCC 13+ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85487 --------- Co-authored-by: Mikhail Bautin <[email protected]> Co-authored-by: Ash Vardanian <[email protected]> * Fix: Capacity checks in C# tests * Docs: Add doc-strings in C# * Make: Verbose C# logging in debug builds * Docs: Describe serialization in GoLang * Make: Drop Java & JS API references Compiling and introspecting docstrings in Sphinx is extremely flaky. It's safer to simply describe the usage patterns in the `README.md`. * Add: Load from path in Java (#410) * Improve: Avoid sorting on small "refines" * Docs: Cover JIT-compiled Python examples * Fix: `index.copy()` trying to `memcpy(*, NULL, *)` * Docs: UB in C++ Example (#415) Co-authored-by: Ash Vardanian <[email protected]> * Improve: Catch UB with tests * Docs: Rearrange * Fix: Reserving contexts post-reload * Improve: Detect more failures in tests * Improve: Log failing lines * Fix: Clamp before down-casting to `i8_t` (#422) Previously we were down-casting floats to the target type (e.g. int8_t), and then clamping to [-100, 100] range. This means that e.g. 129 would be cast to -127 and then converted to -100, in stead of becoming 100 The fix does clamping first, and then casts the resulting number (which is guaranteed to be in range [-100, 100], due to clamping) from source type to target int8_t. Given the clamping, this will never overflow. --------- Co-authored-by: Ash Vardanian <[email protected]> * Fix: Concurrency bug in high-K search When calling `index_dense_gt`, the thread lock was not propagating with the `search_result_t`. That is a an error-prone API. When too many threads are running in parallel (ideally, more than physical CPU cores) another thread may start reusing the `context_t` before the original caller finishes exporting entries with `dump_to`. This solution is backwards compatible and passes the tests. * Make: Manually bump version to 2.13.0 We can't yet rely on the SemVer tool semantic-release/release-notes-generator#633 (comment) * Improve: Attempt to implement batch-metrics * Add: Batch-capable metrics * Add: `misaligned_ptr_gt` comparators * Improve: Separate `error_t` constructors This makes debugging easier, as it's simpler to trace where the error message is being set. * Improve: Support `enum` slots Tracing implicit conversions of `std::uint32_t` and other primitive types isn't always easy in concurrent apps. This commit adds support for `enum` types to be used for safer implementation of `index_gt` specializations. * Improve: Ranges-V3 compatibility * Add: Preliminary support for batch metrics * Add: Batch-parallel refinements * Add: `MANIFEST.in` for `py.typed` (#425) Adding type annotation for Python native modules solves the `Skipping analyzing "usearch.index" module` warning due to `missing library stubs or py.typed marker`. Closes #424 * Fix: Clear cast buffer before bitwise ORs for `b1x8_t` (#428) When converting floating point arrays to binary, we use bitwise OR operations to set the relevant bits in the output buffer to 1. We do nothing if the bit is zero, so we assume that the bit is zero to start with. The `memset` statement makes sure this assumption holds. * Fix: `esm` duplicate import bug in `jest` (#420) Closes #418 Closes #426 * Fix: build.gradle deprecations * Fix: ESM build support (#433) Closes #426 Relates to #420 * Fix: `capacity()` assertion in Rust (#436) Closes #432 * Fix: Computing `stats(i).max_edges` * Add: Returning `computed_distances_in_refines` In high-connectivity graphs, the number of distance computations can be dominated by the number of "refine" heuristic computations performed by the core structure. The extended `add_result_t` now includes both: - `computed_distances_in_refines` - `computed_distances_in_reverse_refines` This commit also extends the documentation. * Add: Profiling attributes for `index_gt` * Fix: Preserve thread limits after `fork()` * Improve: Benchmarks self-recall support and `.bbin` This patch adds support for partial datasets, without ground truth neighborhood data. It also adds support for `.bbin` binary, `.hbin` half-precision, and `.dbin` double-precision input vector files/ * Fix: Printing progress between exit * Docs: Fix spelling * Fix: Wolfram bindings (#437) Co-authored-by: Ash Vardanian <[email protected]> * Fix: Pre-reserve enough threads for C users This indirectly fixes the crash in C# layer * Revert: Parallel metrics * Fix: Updating the `entry_slot_` node * Improve: Enable single-threaded update tests * Make: Bump version * Fix: `flat_hash_multi_set_gt::reset` double-free * Fix: Not enough memory in `fork()` * Make: Bump to SimSIMD v5 * Fix: Missing SimSIMD v5 capability names * Improve: Detecting copy & move issues * Fix: Compilation w. explicit `template class` * Improve: Bypass UBSan NULL dereferencing warning * Improve: Minimize alignment issues * Make: Disable `bf16` on MacOS * Make: Link to GitHub repo * Fix: Conditional `call_key` compilation in MSVC * Fix: Unary minus on unsigned distances * Make: Disable `bf16` in JS * Fix: Compatibility with pre-v2.10 Closes #423 * Improve: Test wrong number of dimensions in Rust (#413) Closes #412 --------- Co-authored-by: Julius Brummack <[email protected]> * Fix: Handle wrong dimensionality in Rust * Fix: Overwriting `SIMSIMD_DYNAMIC_DISPATCH` * Make: Upgrade Java version * Fix: Spelling mistakes * Fix: `sprintf` deprecated * Fix: `-Wpass-failed=transform-warning` * Fix: Memory pinning on `Add` in C# * Make: Specify Java distribution * Fix: Pin memory in gets (C#) * Make: Skip `PersistAndRestore` in CI on MacOS * Make: Upgrade Docker action This fixes a GitHub CI warning about the deprecated NodeJS version. * Fix: `view_from_buffer` is unsafe in Rust Closes #453 Co-authored-by: Andrew Dirksen <[email protected]>" * Fix: `view_from_buffer` is unsafe in Rust Closes #453 Co-authored-by: Andrew Dirksen <[email protected]> * Make: Upgrade SimSIMD * Docs: Index header has no capacity The lack of capacity data is intended. Reserving memory is a non-persistent operation by nature, and we shouldn't save that metadata on the disk. Closes #452 Co-authored-by: Christopher Yim <[email protected]> * Fix: Aggressive neighborhood checks on updates * Fix: `update()` bug detect with non-POD keys This bug was tough to spot. Apple Clang was the only one that caught it. The `-O0` flags were explicitly added to expose more symbols for debugging. More `uint40_t` tests were added. * Fix: Align vector type w index in C# (#456) Co-authored-by: Ash Vardanian <[email protected]> * Make: Versioning in pre-release CI * Make: Switch from SemanticRelease to TinySemVer --------- Co-authored-by: Jaysen Marais <[email protected]> Co-authored-by: Antonio Andelic <[email protected]> Co-authored-by: Narek Galstyan <[email protected]> Co-authored-by: Adolfo Garcia <[email protected]> Co-authored-by: Trevor McCulloch <[email protected]> Co-authored-by: Robert Schulze <[email protected]> Co-authored-by: Mikhail Bautin <[email protected]> Co-authored-by: Mikhail Bautin <[email protected]> Co-authored-by: SheldonFung <[email protected]> Co-authored-by: James Braza <[email protected]> Co-authored-by: cinchen <[email protected]> Co-authored-by: Mark Reed <[email protected]> Co-authored-by: John <[email protected]> Co-authored-by: batracos <[email protected]> Co-authored-by: Ziyang Hu <[email protected]> Co-authored-by: Julius Brummack <[email protected]> Co-authored-by: Julius Brummack <[email protected]> Co-authored-by: Andrew Dirksen <[email protected]> Co-authored-by: Christopher Yim <[email protected]> Co-authored-by: Britt <[email protected]>
It looks like v8.0.0 of conventional-changelog-conventionalcommits was released about an hour ago. This causes the semantic-release "generateNotes" step of plugin "@semantic-release/release-notes-generator" to fail:
Reverting conventional-changelog-conventionalcommits back to the v7.x.x series makes this release run fine again.
The text was updated successfully, but these errors were encountered: