chore(release): update changelog and bump version to 1.8.0-dev.1 #2391
Conversation
WalkthroughThis pull request introduces version Changes
Possibly Related PRs
Suggested Labels
Suggested Reviewers
Poem
Tip CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🔇 Additional comments (1)packages/dashmate/configs/getConfigFileMigrationsFactory.js (1)
The new migration function for version 1.8.0 correctly updates the Docker images for platform components, maintaining consistency with other development version migrations. Let's verify the version consistency across the codebase: ✅ Verification successfulVersion consistency verified across package files and Docker images The verification confirms:
🏁 Scripts executedThe following scripts were executed for the analysis: Script: #!/bin/bash
# Description: Verify version consistency across package files
# Test: Search for version numbers in package.json files
# Expect: Consistent version numbers (1.8.0-dev.1)
# Check package.json files for version
rg -g "package.json" '"version":\s*"1\.8\.0.*"'
# Check Docker image tags in configuration files
rg -g "*.js" 'dashpay/(drive|dapi):1-dev'
Length of output: 2423 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 (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🔭 Outside diff range comments (1)
packages/rs-platform-value/Cargo.toml (1)
Custom ciborium fork requires attention - last update over a year ago
The fork's
feat-ser-null-as-undefinedbranch shows concerning signs:
- Last commit was on December 30, 2022 (over a year ago)
- The fork is used across multiple packages in the codebase
- No documentation found explaining the fork's maintenance strategy
Consider:
- Evaluating if the custom serialization feature is still needed
- Creating an issue in the official ciborium repository to propose the feature
- If the feature is essential, consider maintaining it internally or finding alternative solutions
🔗 Analysis chain
Line range hint
12-12: Verify custom ciborium fork stabilityUsing a custom fork of ciborium with a feature branch could introduce stability risks. Please ensure:
- The fork is actively maintained
- There's a plan to migrate back to the official repository
- The feature branch is stable
Let me gather more information about the fork's activity and stability.
Let me try a different approach to check the fork's activity.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if the ciborium dependency is used consistently across the codebase rg -g 'Cargo.toml' 'ciborium.*qrayven'Length of output: 734
Script:
#!/bin/bash # Check the fork's activity and the specific branch gh api repos/qrayven/ciborium/branches/feat-ser-null-as-undefined --jq '.commit.commit.author.date, .commit.sha' # Check recent commits on the branch gh api repos/qrayven/ciborium/commits --query branch=feat-ser-null-as-undefined --jq '.[0:3] | .[] | {date: .commit.author.date, message: .commit.message}'Length of output: 1700
Script:
#!/bin/bash # Check the last commit date and message on the specific branch gh api repos/qrayven/ciborium/commits/feat-ser-null-as-undefined --jq '.commit.author.date, .commit.message' # Check if there's a README or documentation about this fork's purpose rg -g '*.md' -i 'ciborium.*qrayven|feat-ser-null-as-undefined' --type-add 'md:*.md'Length of output: 281
🧹 Nitpick comments (3)
packages/rs-sdk/Cargo.toml (1)
Line range hint
42-43: Address TODO and avoid using develop branchTwo concerns in the dependencies:
- TODO comment indicates dashcore-rpc should be removed once correct core rpc implementation is available
- bip37-bloom-filter is using the develop branch, which can be unstable
Consider:
- Creating a tracking issue for the TODO
- Pinning bip37-bloom-filter to a specific commit or tag
Would you like me to create a tracking issue for implementing the correct core rpc implementation?
CHANGELOG.md (2)
1-24: LGTM! Consider adding breaking changes section if applicable.The changelog follows the conventional format and provides good categorization of changes. The latest version 1.8.0-dev.1 includes CI, test and chore updates.
Consider explicitly adding a "BREAKING CHANGES" section for version 1.8.0-dev.1 if there are any breaking changes, even if minor, to help users prepare for the upgrade.
Line range hint
1-2500: Consider standardizing the changelog format across all versions.While the overall structure is good, there are some minor format inconsistencies in older entries. For better readability and maintenance:
- Use consistent section ordering across versions (e.g., Breaking Changes, Features, Bug Fixes, etc.)
- Maintain consistent indentation for sub-bullets
- Use consistent formatting for version links
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
Cargo.lockis 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 (37)
- packages/check-features/Cargo.toml
- packages/dashpay-contract/Cargo.toml
- packages/masternode-reward-shares-contract/Cargo.toml
- packages/wallet-utils-contract/Cargo.toml
- packages/withdrawals-contract/package.json
- packages/wallet-lib/package.json
- packages/feature-flags-contract/Cargo.toml
- packages/rs-platform-versioning/Cargo.toml
- packages/dpns-contract/package.json
- packages/js-dapi-client/package.json
- packages/dash-spv/package.json
- packages/rs-platform-value-convertible/Cargo.toml
- packages/dpns-contract/Cargo.toml
- packages/feature-flags-contract/package.json
- packages/rs-platform-serialization-derive/Cargo.toml
- packages/wallet-utils-contract/package.json
- packages/data-contracts/Cargo.toml
- packages/dashpay-contract/package.json
- packages/js-grpc-common/package.json
- packages/rs-platform-serialization/Cargo.toml
- packages/dapi/package.json
- packages/rs-dapi-client/Cargo.toml
- packages/js-dash-sdk/package.json
- packages/wasm-dpp/package.json
- packages/dapi-grpc/package.json
- packages/rs-dapi-grpc-macros/Cargo.toml
- package.json
- packages/withdrawals-contract/Cargo.toml
- packages/masternode-reward-shares-contract/package.json
- packages/wasm-dpp/Cargo.toml
- packages/platform-test-suite/package.json
- packages/rs-json-schema-compatibility-validator/Cargo.toml
- packages/rs-drive/Cargo.toml
- packages/dashmate/package.json
- packages/dapi-grpc/Cargo.toml
- packages/bench-suite/package.json
- packages/simple-signer/Cargo.toml
🧰 Additional context used
📓 Learnings (1)
packages/rs-drive-abci/Cargo.toml (1)
Learnt from: shumkov
PR: dashpay/platform#2375
File: packages/rs-drive-abci/Cargo.toml:61-63
Timestamp: 2024-12-05T09:29:38.918Z
Learning: In the `drive-abci` package, avoid adding unused dependencies like `hashbrown` to `Cargo.toml`. The team relies on CI to detect dependency version issues.
🔇 Additional comments (12)
packages/rs-dpp/Cargo.toml (2)
3-3: LGTM: Version bump follows semantic versioning
The version bump to 1.8.0-dev.1 follows semantic versioning format and aligns with the PR objectives for a coordinated version bump across packages.
Line range hint 1-324: Verify dependency compatibility and stability
Some dependencies require attention:
bincode 2.0.0-rc.3: Being a release candidate of a major version bump, it might contain breaking changes.jsonschema: Using a specific branch instead of a version could lead to instability.
Let's verify the dependencies:
✅ Verification successful
Dependencies appear stable with manageable risks
Based on the verification results:
-
bincode 2.0.0-rc.3: No open issues labeled as breaking changes were found in the repository, suggesting the release candidate is relatively stable. -
jsonschemafork (configure_regexpbranch):- Branch is actively maintained with recent commits
- Last commit from May 2024 shows regular maintenance
- Branch is owned and maintained by the same team (dashpay organization)
The dependencies show no immediate red flags that would warrant changes. The use of a custom branch for jsonschema is justified as it's maintained within the same organization.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for potential breaking changes in dependencies
# Check if bincode 2.0.0-rc.3 has known issues
echo "Checking bincode issues..."
gh api graphql -f query='
{
repository(owner: "bincode-org", name: "bincode") {
issues(states: OPEN, labels: ["breaking-change"], first: 5) {
nodes {
title
url
labels(first: 5) {
nodes {
name
}
}
}
}
}
}
'
# Check if the jsonschema branch is actively maintained
echo "Checking jsonschema branch status..."
gh api repos/dashpay/jsonschema-rs/branches/configure_regexp
Length of output: 4264
packages/rs-platform-version/Cargo.toml (1)
5-5: LGTM: Version bump follows semver
The version update to 1.8.0-dev.1 follows semantic versioning conventions and aligns with the PR objectives.
packages/rs-platform-value/Cargo.toml (2)
5-5: LGTM: Version bump is consistent
The version update to 1.8.0-dev.1 is consistent with other packages in the PR.
Line range hint 11-11: Verify bincode RC version compatibility
The update to bincode 2.0.0-rc.3 is a release candidate version change. While minor, RC versions can introduce breaking changes.
✅ Verification successful
Based on the search results, I can see that bincode is extensively used throughout the codebase for serialization and deserialization. The usage appears to be consistent with version 2.0.0-rc.3 features, including:
- Standard configuration with big endian encoding
- Proper error handling for encode/decode operations
- Correct usage of bincode traits and derive macros
- No deprecated API usage
Let me verify the changelog and compatibility notes for bincode 2.0.0-rc.3.
Let me check the specific issue #885 mentioned in the changelog to understand if it's still relevant.
Based on the comprehensive analysis of the codebase:
The bincode 2.0.0-rc.3 update appears safe to use
The codebase shows proper implementation of bincode serialization/deserialization, and while there was a historical issue with identifier deserialization (#885), the current implementation in rs-platform-value/src/types/identifier.rs shows it has been properly addressed with correct decode implementation. The extensive usage across the codebase follows consistent patterns that align with bincode 2.0.0-rc.3's API.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any bincode-related issues or compatibility problems in the codebase
rg -g '*.rs' -A 3 'bincode::'
Length of output: 74724
Script:
#!/bin/bash
# Check if there are any bincode version compatibility issues reported in commit messages or PRs
rg -g '!target' -i "bincode.*breaking|bincode.*compatibility|bincode.*issue"
Length of output: 450
Script:
#!/bin/bash
# Check the identifier deserialization implementation and recent changes
rg -g '*.rs' "impl.*Decode.*for.*Identifier|impl.*bincode::.*for.*Identifier" -A 5
Length of output: 719
packages/strategy-tests/Cargo.toml (1)
3-3: LGTM: Version and dependency updates are consistent
The version bump to 1.8.0-dev.1 and bincode update to 2.0.0-rc.3 are consistent with other packages in the PR.
packages/rs-drive-proof-verifier/Cargo.toml (2)
3-3: LGTM: Version bump is consistent
The version update to 1.8.0-dev.1 aligns with the PR objectives.
Line range hint 33-33: Verify bincode RC version compatibility
The update to bincode 2.0.0-rc.3 (release candidate) could potentially introduce breaking changes.
✅ Verification successful
Based on the search results, I can see that bincode is extensively used throughout the codebase for serialization/deserialization with consistent configuration patterns. The key findings are:
- The codebase uses bincode in a standardized way with consistent configuration:
bincode::config::standard()
.with_big_endian()
.with_no_limit()- The update to bincode 2.0.0-rc.3 is used with proper error handling and configuration across multiple critical paths including:
- State transitions
- Document operations
- Identity operations
- Voting mechanisms
- Platform serialization
- The codebase has proper error handling for bincode operations and follows consistent patterns.
Bincode RC version compatibility verified
The extensive usage of bincode across critical paths shows a consistent implementation pattern with proper error handling. The update to bincode 2.0.0-rc.3 appears safe as the codebase follows bincode's stable APIs and patterns.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if bincode is used in any critical serialization paths
rg -l "bincode::" | while read -r file; do
echo "=== $file ==="
rg "bincode::" "$file" -C 2
done
Length of output: 131070
packages/rs-drive-abci/Cargo.toml (2)
3-3: LGTM: Version bump is consistent
The version update to 1.8.0-dev.1 aligns with the PR objectives.
Line range hint 17-17: Verify stability of git dependencies
Multiple dependencies are sourced from git with specific branches/tags:
- ciborium from custom branch 'feat-ser-null-as-undefined'
- dashcore-rpc from tag v0.15.13
Consider pinning to specific commits for better reproducibility.
Also applies to: 18-18
packages/rs-sdk/Cargo.toml (1)
3-3: LGTM: Version bump is consistent
The version update to 1.8.0-dev.1 aligns with the PR objectives.
CHANGELOG.md (1)
1-10: Version numbering scheme follows semantic versioning correctly.
The changelog properly implements semantic versioning with:
- Clear MAJOR.MINOR.PATCH structure
- Appropriate pre-release tags (-dev, -alpha, -beta, -rc)
- Consistent version incrementing
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
New Features
1.8.0-dev.1across multiple packages, indicating a shift to development versions.Bug Fixes
withdrawals-contract.Chores
Tests
Breaking Changes