Conversation
Patel-Raj11
requested review from
nhartner,
nkramer44 and
sappenin
as code owners
| git checkout main | ||
| git pull | ||
| ``` | ||
| 2. Create a new release branch from main (e.g. `releases/v6.0` for major version release, `releases/v6.1` for minor version release) |
There was a problem hiding this comment.
@sappenin
I kept this step because it's the convention that is currently being followed in xrpl4j release process. Since we are tagging the commits, we can skip creating the release branches and rely on git tags to know what should be the next version to release. WDYT?
If we decide to move away from release branches, then we won't be able to update the patch version in advance (as we do in step 9 currently). Would that cause any issue? Because currently in xrpl.js and xrpl-py we always update the version before doing any release.
Also, in xrpl.js and xrpl-py we push that latest released version to main branch, could we follow the same convention in xrpl4j?
There was a problem hiding this comment.
Thinking about it a bit more, let's keep the release branch pattern + versioning strategy for now - I haven't decided how we should track patches if we only tag.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #705 +/- ##
=========================================
Coverage 92.91% 92.91%
Complexity 2220 2220
=========================================
Files 437 437
Lines 6025 6025
Branches 536 536
=========================================
Hits 5598 5598
Misses 279 279
Partials 148 148 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| git checkout main | ||
| git pull | ||
| ``` | ||
| 2. Create a new release branch from main (e.g. `releases/v6.0` for major version release, `releases/v6.1` for minor version release) |
There was a problem hiding this comment.
Thinking about it a bit more, let's keep the release branch pattern + versioning strategy for now - I haven't decided how we should track patches if we only tag.
|
|
||
| 3. Set intended release version | ||
| ``` | ||
| mvn versions:set -DnewVersion=6.1.0 |
There was a problem hiding this comment.
| mvn versions:set -DnewVersion=6.1.0 | |
| mvn versions:set -DnewVersion=6.1.0-SNAPSHOT |
There was a problem hiding this comment.
Only SNAPSHOT should be committed into the repo. The non-SNAPSHOT versions are only interstitially existing on whatever machine deploys the artifacts.
| git tag v6.1.0 | ||
| git push origin v6.1.0 | ||
| ``` | ||
| 7. Generate and deploy artifacts to [maven central repository](https://central.sonatype.com/) (This would prompt to sign the artifacts using private key) |
There was a problem hiding this comment.
Here we would execute the version bump, to deploy:
mvn versions:set -DnewVersion=6.1.0
| 8. Approve the release on [maven central repository](https://central.sonatype.com/) | ||
| 9. Update the version to next patch version, commit and push to remote | ||
| ``` | ||
| mvn versions:set -DnewVersion=6.1.1 |
There was a problem hiding this comment.
| mvn versions:set -DnewVersion=6.1.1 | |
| mvn versions:set -DnewVersion=6.1.1-SNAPSHOT |
| 9. Update the version to next patch version, commit and push to remote | ||
| ``` | ||
| mvn versions:set -DnewVersion=6.1.1 | ||
| git commit -m "update version to 6.1.1" |
There was a problem hiding this comment.
| git commit -m "update version to 6.1.1" | |
| git commit -m "update version to 6.1.1-SNAPSHOT" |
| ``` | ||
| 2. Create a new release branch from main (e.g. `releases/v6.0` for major version release, `releases/v6.1` for minor version release) | ||
| ``` | ||
| git checkout -b releases/v6.1 |
There was a problem hiding this comment.
Looking at this more, I worry people will think v6.1 is normative. Maybe we should do something like v[major].[minor] and when we want to bump, say something like this:
Increment the version from v[major].[minor].[patch]-SNAPSHOT to v[major].[minor].[patch+1]-SNAPSHOT. For example, increment from v6.0.0-SNAPSHOT to v6.0.1-SNAPHSOT.
2 participants
This PR documents manual release process for
xrpl4jartifacts. These steps would be used as a guide for release automation and serve as future reference, in the event we need to manually releasexrpl4jpackage.