-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(release): update changelog and bump version to 1.6.0-dev.1 #2350
Conversation
WalkthroughThe pull request introduces version Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Warning Rate limit exceeded@shumkov has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 10 minutes and 50 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (5)
packages/rs-drive/Cargo.toml (2)
Line range hint
6-11
: Fix syntax error in authors listThere's a missing closing bracket in Wisdom's email address.
- "Wisdom Ogwu <[email protected]", + "Wisdom Ogwu <[email protected]>",
Line range hint
108-108
: Consider optimizing default featuresThe default features now include "full", which brings in many optional dependencies like ciborium, serde, bs58, etc. This could unnecessarily increase the binary size for users who don't need all these features.
Consider if all these features should be enabled by default or if they should be opt-in.
package.json (1)
Security update required for follow-redirects dependency
The security scan reveals critical findings that need immediate attention:
[email protected]
has a moderate severity vulnerability (CVE published on March 14, 2024) related to Proxy-Authorization header exposure. This version needs to be updated to1.15.6
which contains the fix.Other dependencies appear to be at secure versions:
[email protected]
is the patched version that fixes the DoS vulnerability[email protected]
is the patched version addressing the DoS vulnerability[email protected]
is above the vulnerable range for ReDoS issues[email protected]
is the patched version that fixes prototype pollution🔗 Analysis chain
Line range hint
89-126
: Verify security advisories for critical dependenciesThe resolutions section includes several security-related updates. Let's verify there are no known vulnerabilities in the specified versions.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for security advisories for critical dependencies # Check for vulnerabilities in critical dependencies echo "Checking security advisories for critical dependencies..." # Define critical packages to check packages=( "follow-redirects:1.15.5" "ws:8.17.1" "body-parser:1.20.3" "semver:7.5.3" "protobufjs:6.11.4" ) # Check each package for pkg in "${packages[@]}"; do IFS=':' read -r name version <<< "$pkg" echo "Checking $name@$version..." gh api graphql -f query='{ securityVulnerabilities(first:5, ecosystem:NPM, package:"'"$name"'") { nodes { advisory { summary severity publishedAt } vulnerableVersionRange firstPatchedVersion { identifier } } } }' doneLength of output: 6972
packages/rs-dpp/Cargo.toml (1)
Line range hint
1-300
: Consider stabilizing git dependencies.While not directly related to this version bump, there are some dependency considerations for future releases:
- The
jsonschema
andciborium
dependencies use git branches instead of tags, which could affect build reproducibility.bincode
is using a release candidate version (2.0.0-rc.3).Consider:
- Moving to tagged versions for git dependencies when stable versions become available
- Planning for the eventual stable release of bincode 2.0.0
CHANGELOG.md (1)
1-1
: LGTM with suggestions for improvementThe changelog is well-structured and follows conventional commit format. A few suggestions for improvement:
- Consider standardizing the version comparison links format. Some entries use:
[v1.6.0-dev.1](https://github.com/dashpay/platform/compare/v1.5.0...v1.6.0-dev.1)
While others use:
(https://github.com/dashevo/platform/compare/v0.22.0-dev.3...v0.22.0-dev.4)
- Some entries could benefit from more detailed descriptions of the changes, especially for breaking changes.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
Cargo.lock
is excluded by!**/*.lock
📒 Files selected for processing (45)
CHANGELOG.md
(1 hunks)package.json
(1 hunks)packages/bench-suite/package.json
(1 hunks)packages/check-features/Cargo.toml
(1 hunks)packages/dapi-grpc/Cargo.toml
(1 hunks)packages/dapi-grpc/package.json
(1 hunks)packages/dapi/package.json
(1 hunks)packages/dash-spv/package.json
(1 hunks)packages/dashmate/package.json
(1 hunks)packages/dashpay-contract/Cargo.toml
(1 hunks)packages/dashpay-contract/package.json
(1 hunks)packages/data-contracts/Cargo.toml
(1 hunks)packages/dpns-contract/Cargo.toml
(1 hunks)packages/dpns-contract/package.json
(1 hunks)packages/feature-flags-contract/Cargo.toml
(1 hunks)packages/feature-flags-contract/package.json
(1 hunks)packages/js-dapi-client/package.json
(1 hunks)packages/js-dash-sdk/package.json
(1 hunks)packages/js-grpc-common/package.json
(1 hunks)packages/masternode-reward-shares-contract/Cargo.toml
(1 hunks)packages/masternode-reward-shares-contract/package.json
(1 hunks)packages/platform-test-suite/package.json
(1 hunks)packages/rs-dapi-client/Cargo.toml
(1 hunks)packages/rs-dapi-grpc-macros/Cargo.toml
(1 hunks)packages/rs-dpp/Cargo.toml
(1 hunks)packages/rs-drive-abci/Cargo.toml
(1 hunks)packages/rs-drive-proof-verifier/Cargo.toml
(1 hunks)packages/rs-drive/Cargo.toml
(1 hunks)packages/rs-json-schema-compatibility-validator/Cargo.toml
(1 hunks)packages/rs-platform-serialization-derive/Cargo.toml
(1 hunks)packages/rs-platform-serialization/Cargo.toml
(1 hunks)packages/rs-platform-value-convertible/Cargo.toml
(1 hunks)packages/rs-platform-value/Cargo.toml
(1 hunks)packages/rs-platform-version/Cargo.toml
(1 hunks)packages/rs-platform-versioning/Cargo.toml
(1 hunks)packages/rs-sdk/Cargo.toml
(1 hunks)packages/simple-signer/Cargo.toml
(1 hunks)packages/strategy-tests/Cargo.toml
(1 hunks)packages/wallet-lib/package.json
(1 hunks)packages/wallet-utils-contract/Cargo.toml
(1 hunks)packages/wallet-utils-contract/package.json
(1 hunks)packages/wasm-dpp/Cargo.toml
(1 hunks)packages/wasm-dpp/package.json
(1 hunks)packages/withdrawals-contract/Cargo.toml
(1 hunks)packages/withdrawals-contract/package.json
(1 hunks)
✅ Files skipped from review due to trivial changes (34)
- packages/bench-suite/package.json
- packages/check-features/Cargo.toml
- packages/dapi-grpc/package.json
- packages/dapi/package.json
- packages/dash-spv/package.json
- packages/dashmate/package.json
- packages/dashpay-contract/Cargo.toml
- packages/dashpay-contract/package.json
- packages/data-contracts/Cargo.toml
- packages/dpns-contract/Cargo.toml
- packages/dpns-contract/package.json
- packages/feature-flags-contract/Cargo.toml
- packages/feature-flags-contract/package.json
- packages/js-dapi-client/package.json
- packages/js-dash-sdk/package.json
- packages/js-grpc-common/package.json
- packages/masternode-reward-shares-contract/Cargo.toml
- packages/masternode-reward-shares-contract/package.json
- packages/platform-test-suite/package.json
- packages/rs-dapi-grpc-macros/Cargo.toml
- packages/rs-json-schema-compatibility-validator/Cargo.toml
- packages/rs-platform-serialization-derive/Cargo.toml
- packages/rs-platform-serialization/Cargo.toml
- packages/rs-platform-value-convertible/Cargo.toml
- packages/rs-platform-version/Cargo.toml
- packages/rs-platform-versioning/Cargo.toml
- packages/simple-signer/Cargo.toml
- packages/wallet-lib/package.json
- packages/wallet-utils-contract/Cargo.toml
- packages/wallet-utils-contract/package.json
- packages/wasm-dpp/Cargo.toml
- packages/wasm-dpp/package.json
- packages/withdrawals-contract/Cargo.toml
- packages/withdrawals-contract/package.json
🔇 Additional comments (21)
packages/rs-platform-value/Cargo.toml (2)
5-5
: Verify version bump consistency across workspace
The version bump to 1.6.0-dev.1
aligns with the PR objectives. Let's verify this version is consistent across all workspace packages.
Line range hint 11-12
: Review dependency stability concerns
Two potential stability concerns in dependencies:
- Using
bincode 2.0.0-rc.3
(release candidate) in a development release - Using
ciborium
from a git repository with branchfeat-ser-null-as-undefined
Consider:
- Is there a stable version of bincode we can use?
- Can we use a published version of ciborium instead of a git dependency?
packages/rs-dapi-client/Cargo.toml (2)
3-3
: LGTM: Version bump follows semantic versioning
The version update from 1.5.0 to 1.6.0-dev.1 correctly indicates a minor version bump with development pre-release tag, which aligns with the PR objectives.
3-3
: Verify version consistency across related packages
Since this is part of a coordinated release, let's verify that the version is consistent across all related packages.
✅ Verification successful
Version consistency verified across all packages
All related packages in both Rust (Cargo.toml) and JavaScript/Node.js (package.json) ecosystems are consistently set to version "1.6.0-dev.1", including:
- 26 Rust packages in Cargo.toml files
- 15 JavaScript packages in package.json files, including the root package.json
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check version consistency across package files
# Expected: All related packages should be updated to version 1.6.0-dev.1
# Check all Cargo.toml files
echo "Checking Cargo.toml files:"
fd Cargo.toml | xargs rg "version = \"1\.6\.0-dev\.1\""
# Check package.json files
echo -e "\nChecking package.json files:"
fd package.json | xargs rg "\"version\": \"1\.6\.0-dev\.1\""
Length of output: 2855
packages/strategy-tests/Cargo.toml (2)
3-3
: LGTM: Version bump aligns with release objectives
The version update to "1.6.0-dev.1" is consistent with the PR's purpose and matches the version updates across other packages.
Line range hint 13-13
: Verify consistent usage of bincode RC version
The dependency on bincode 2.0.0-rc.3 (release candidate) should be consistent across all packages to avoid compatibility issues.
✅ Verification successful
All packages use consistent bincode version 2.0.0-rc.3
The verification shows that all 9 packages in the codebase consistently use bincode version "2.0.0-rc.3", with varying feature configurations. No version inconsistencies were found.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify consistent bincode version usage across all Cargo.toml files
# Search for bincode dependency versions in all Cargo.toml files
echo "Checking bincode versions in Cargo.toml files:"
rg 'bincode.*version.*=.*' -g 'Cargo.toml'
Length of output: 998
packages/rs-drive-proof-verifier/Cargo.toml (3)
Line range hint 39-42
: LGTM: Tenderdash ABCI dependency update
The tenderdash-abci dependency update to tag v1.2.1+1.3.0
while maintaining version 1.2.1
looks correct. The tag format suggests it's aligned with a specific platform version.
3-3
: Verify version consistency across workspace packages
The version bump to 1.6.0-dev.1
aligns with the PR objectives.
✅ Verification successful
Version consistency verified across workspace packages
All Rust packages in the workspace have been updated to version 1.6.0-dev.1
, except for rs-drive-verify-c-binding
which maintains version 1.1.0
. This is consistent with the version bump in the PR.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify version consistency across Cargo.toml files
# Expected: All relevant packages should be updated to 1.6.0-dev.1
# Find all Cargo.toml files and check their versions
fd Cargo.toml --type f --exec grep -H '^version = ' {} \;
Length of output: 1818
Line range hint 31-31
: Consider stability implications of using release candidate dependency
The bincode
dependency is using a release candidate version (2.0.0-rc.3
). While this is a minor RC version bump from rc.2
, it's worth noting that RC versions may have breaking changes or stability issues.
✅ Verification successful
Consider using stable version of bincode or document RC version usage rationale
The verification shows that:
- The RC version
2.0.0-rc.3
is consistently used across all 9 Rust packages in the codebase - This is currently the latest version available on crates.io
- No stable 2.0.0 version has been released yet
Given that:
- The RC version is used consistently throughout the project
- It's the latest available version
- The project appears to require bincode 2.0 features
- There's no stable 2.0.0 alternative available
The use of this RC version appears to be a deliberate choice rather than an oversight. However, it would be beneficial to:
- Document the rationale for using the RC version in the project documentation
- Monitor for the stable 2.0.0 release and plan for migration
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if bincode RC version is used consistently and check for newer stable versions
# Check bincode version usage across all Cargo.toml files
echo "Checking bincode version usage:"
rg 'bincode.*version.*=.*' -g 'Cargo.toml'
# Check latest bincode version from crates.io
echo -e "\nLatest bincode versions from crates.io:"
curl -s https://crates.io/api/v1/crates/bincode | jq -r '.versions[0:3] | map({num:.num, yanked:.yanked})'
Length of output: 1337
packages/dapi-grpc/Cargo.toml (1)
4-4
: LGTM! Verify version consistency across the repository.
The version bump to 1.6.0-dev.1
follows semantic versioning and matches the PR objectives.
Let's verify version consistency across other package files:
packages/rs-drive-abci/Cargo.toml (4)
3-3
: LGTM: Version bump follows semantic versioning
The version update to 1.6.0-dev.1
aligns with the PR objectives and follows semantic versioning conventions.
Line range hint 94-104
: LGTM: Enhanced testing capabilities
The additional DPP features and testing configurations will improve the test coverage and development experience. The features are well-organized and focused on specific testing needs.
Also applies to: 105-105
Line range hint 115-120
: LGTM: Well-organized feature flags
The feature configuration is clean and modular with appropriate defaults and clear separation of concerns.
Line range hint 15-15
: Verify compatibility with updated dependencies
Several critical dependencies have been updated:
bincode
to release candidate2.0.0-rc.3
dashcore-rpc
to tagv0.15.8
tracing-subscriber
with expanded featuresmetrics-exporter-prometheus
to0.15
tokio
to1.40
Let's verify the compatibility of these versions:
Also applies to: 29-29, 45-45, 64-64, 71-71
✅ Verification successful
Dependencies are consistently versioned across workspace packages
The verification shows:
bincode 2.0.0-rc.3
is consistently used across all workspace packages and is currently the latest versiondashcore-rpc v0.15.8
is consistently pinned across packagesmetrics-exporter-prometheus 0.15
is only used in rs-drive-abcitokio 1.40
is consistently used across packages with appropriate feature sets
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for potential compatibility issues with updated dependencies
# Check if there are any other packages in the workspace using different versions
echo "Checking for version mismatches across workspace:"
rg --type toml "bincode.*2\.0\.0" -A 1
rg --type toml "dashcore-rpc.*v0\.15\.8" -A 1
rg --type toml "metrics-exporter-prometheus.*0\.15" -A 1
rg --type toml "tokio.*1\.40" -A 1
# Check if bincode RC version is the latest
curl -s https://crates.io/api/v1/crates/bincode | jq -r '.versions[0].num'
Length of output: 4419
packages/rs-sdk/Cargo.toml (3)
3-3
: LGTM: Version bump aligns with PR objectives
The version update to "1.6.0-dev.1" follows semantic versioning and correctly reflects the development status of this release.
Line range hint 82-106
: LGTM: Well-structured feature configuration
The feature flags are well-documented with clear purposes and precedence rules. The testing strategy with offline/network testing options provides good flexibility for different testing scenarios.
Line range hint 15-15
: Consider using tagged versions instead of branches for dependencies
Using Git branches (feat-ser-null-as-undefined
for ciborium and develop
for bip37-bloom-filter) could lead to build reproducibility issues as branches can change unexpectedly. Consider:
- Using specific commits or tags
- Publishing these dependencies to crates.io
Let's check if these repositories have any tagged releases we could use:
Also applies to: 37-37
packages/rs-drive/Cargo.toml (2)
4-4
: LGTM: Version bump aligns with PR objectives
The version bump to 1.6.0-dev.1 is consistent with the release plan.
Line range hint 17-17
: Verify stability of bincode release candidate
Using bincode 2.0.0-rc.3 in production could be risky as it's a release candidate. Please ensure:
- This version is required for compatibility
- There are no known issues that could affect production
package.json (1)
3-3
: Verify version consistency across workspace packages
The version bump to 1.6.0-dev.1
should be reflected across all workspace packages to maintain consistency.
✅ Verification successful
Version inconsistencies detected in workspace packages
The following packages have different version numbers than the root package.json (1.6.0-dev.1):
- packages/dash-spv/package.json: 2.6.0-dev.1
- packages/js-dash-sdk/package.json: 4.6.0-dev.1
- packages/wallet-lib/package.json: 8.6.0-dev.1
Version differences are expected - these are independently versioned public packages
The version differences are intentional and correct. The packages with different versions are:
@dashevo/dash-spv
(2.6.0-dev.1)dash
(js-dash-sdk, 4.6.0-dev.1)@dashevo/wallet-lib
(8.6.0-dev.1)
These are public packages (not marked as private) with their own major version numbers, indicating they are independently versioned. This is a common practice in monorepos where public packages maintain their own semantic versioning while sharing the same development cycle.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check version consistency across all workspace packages
# Find all package.json files in workspace packages and extract their versions
echo "Checking package versions:"
for pkg in packages/*/package.json; do
echo "$pkg: $(jq -r '.version' "$pkg")"
done
# Verify all versions match the root package.json version
mismatch_count=$(for pkg in packages/*/package.json; do
if [ "$(jq -r '.version' "$pkg")" != "1.6.0-dev.1" ]; then
echo "$pkg has mismatched version"
fi
done | wc -l)
if [ "$mismatch_count" -gt 0 ]; then
echo "Error: Found version mismatches"
exit 1
fi
Length of output: 6094
Script:
#!/bin/bash
# Let's check if these packages have their own versioning scheme by looking at their git history
for pkg in "dash-spv" "js-dash-sdk" "wallet-lib"; do
echo "=== Checking history for $pkg ==="
git log -n 5 --oneline -- "packages/$pkg/package.json"
done
Length of output: 417
Script:
#!/bin/bash
# Let's check the package.json files of these packages to understand their versioning
for pkg in "dash-spv" "js-dash-sdk" "wallet-lib"; do
echo "=== Package details for $pkg ==="
echo "Name and version:"
jq '{name, version}' "packages/$pkg/package.json"
echo "Private field:"
jq '.private' "packages/$pkg/package.json"
echo "---"
done
Length of output: 1205
packages/rs-dpp/Cargo.toml (1)
3-3
: LGTM! Version bump follows semantic versioning.
The version update to "1.6.0-dev.1" follows the semantic versioning format and aligns with the PR objectives for this release.
Let's verify version consistency across the workspace:
✅ Verification successful
Version consistency verified across workspace packages
All 26 Rust packages in the workspace have been updated to version "1.6.0-dev.1", showing consistent versioning across the entire platform.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check version consistency across workspace packages
# Expected: All related packages should be updated to 1.6.0-dev.1
# Find all Cargo.toml files and check their versions
fd --type f "Cargo.toml" --exec grep -H "^version = \"1.6" {} \;
Length of output: 1756
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
CHANGELOG.md (1)
1-1
: LGTM with suggestions for improvementThe changelog is well-maintained and follows conventional commit format. The changes are properly categorized and documented with PR references.
Consider these improvements:
- Avoid duplicate section headings within the same version block. For example, there are multiple "Miscellaneous Chores" sections that could be consolidated.
- Consider using consistent heading levels across all version blocks to improve readability.
- ### Miscellaneous Chores + ## Miscellaneous Chores * item 1 * item 2 - ### Miscellaneous Chores * item 3 * item 4
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
CHANGELOG.md
(1 hunks)
🧰 Additional context used
🪛 Markdownlint (0.35.0)
CHANGELOG.md
50-50: null
Multiple headings with the same content
(MD024, no-duplicate-heading)
Issue being fixed or feature implemented
Release new Dash Platform version
What was done?
How Has This Been Tested?
None
Breaking Changes
None
Checklist:
For repository code-owners and collaborators only
Summary by CodeRabbit
Release Notes for Version 1.6.0-dev.1
New Features
Bug Fixes
Chores
This release enhances functionality and stability, improving user experience across the Dashpay platform.