Document manual release process #705
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,48 @@ | ||||||
|
|
||||||
| # Release Guide | ||||||
|
|
||||||
| This document describes the manual release process for xrpl4j. | ||||||
|
|
||||||
| ## Stable Releases | ||||||
|
|
||||||
| 1. Checkout main and pull in latest changes from remote | ||||||
| ``` | ||||||
| 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) | ||||||
| ``` | ||||||
| git checkout -b releases/v6.1 | ||||||
|
Collaborator
There was a problem hiding this comment. Looking at this more, I worry people will think Increment the version from |
||||||
| ``` | ||||||
|
|
||||||
| 3. Set intended release version | ||||||
| ``` | ||||||
| mvn versions:set -DnewVersion=6.1.0 | ||||||
|
Collaborator
There was a problem hiding this comment.
Suggested change
Collaborator
There was a problem hiding this comment. Only |
||||||
| ``` | ||||||
| 4. Commit and push changes in `pom.xml` files created by step #3. | ||||||
| 5. Verify Integration tests that executes on `Devnet` passes in GitHub actions. Integration tests that executes on | ||||||
| `Testnet` might fail as the amendment would generally not be available on `Testnet` yet. | ||||||
| 6. Create a new tag for the release and push to remote | ||||||
| ``` | ||||||
| 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) | ||||||
|
Collaborator
There was a problem hiding this comment. Here we would execute the version bump, to deploy: |
||||||
| ``` | ||||||
| mvn clean deploy -DskipTests -P release | ||||||
| ``` | ||||||
| 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 | ||||||
|
Collaborator
There was a problem hiding this comment.
Suggested change
|
||||||
| git commit -m "update version to 6.1.1" | ||||||
|
Collaborator
There was a problem hiding this comment.
Suggested change
|
||||||
| git push | ||||||
| ``` | ||||||
| 10. Generate release notes on GitHub using `v6.1.0` git tag. | ||||||
| 11. Subsequent bug fixes if any are merged into `releases/v6.1` branch and released as patch version upgrades | ||||||
|
|
||||||
| ## Release candidates | ||||||
|
|
||||||
| Steps remains same as stable release. We would follow Semantic Versioning and name the version something like `6.1. | ||||||
| 0-rc.1`. In the event when the change we want to release as release candidate is not merged in the `main` branch, we | ||||||
| would release it from feature branch itself and tag the commit of feature branch. | ||||||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
@sappenin
I kept this step because it's the convention that is currently being followed in
xrpl4jrelease 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.jsandxrpl-pywe always update the version before doing any release.Also, in
xrpl.jsandxrpl-pywe push that latest released version tomainbranch, could we follow the same convention inxrpl4j?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.
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.