2 minutes to read
Creating a New Release
Before You Begin
-
We use semantic versioning and we also keep a changelog. All of this is done on a best-efforts basis.
-
A release consists of five parts, each explained below.
GitHub
-
Update the version in
gradle.properties
. -
Update the changelog.
-
Create a section for the version.
-
Copy to the new section all unreleased features which will be in the release.
-
Commit and push the new version.
-
-
Copy the contents of the changelog for this version to the description then submit.
-
Set the version as vX.Y.Z.
-
Run
./gradlew createDist
to zip the source in build (the distribution file). -
Add the zipped file and submit the new release.
Docker Hub
The image build for rdmueller/doctoolchain depends on the GitHub repo docToolchain/docker-image.
-
Update the Dockerfile to reflect the new version.
-
Create a new release.
-
Reference the GitHub release in the changelog (the build on Dockerhub will be automatically triggered).
Important! Currently, the autobuild only works for paying customers. To manually build and upload the image, download the repo, switch to branch ng-beta
, cd to the alpine
folder and execute docker build -t rdmueller/doctoolchain:v2.0.0-rc15 .
. After that, use Docker Desktop to push the resulting image to Docker Hub.
Blog Post
Create a blog post to announce the new release. The SDKMAN! announcement will reference it.
docToolchain-Wrapper (dtcw)
Everything went well? Great! Now let’s update the version used in the wrapper:
SDKMAN!
A GitHub action sdkman deploy has been created to deploy to SDKMAN!
-
Set the version to the same as for the other releases, but without the prepended v: X.Y.Z.
-
Use as a download link the link to the
docToolchain-dist.zip
from the GitHub release. Tip: the link looks like https://github.com/docToolchain/docToolchain/releases/download/v1.3.1/docToolchain-dist.zip.
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.