Releasing new version
The release procedure is currently an almost fully automated GitHub Action workflow.
-
The release is mostly automated these days. To start a release all you need to do is to run the GitHub Action release workflow for 4.1 or 4.2. Use the 4.2-branch version of the workflow in both cases.
-
The workflow will take care of building all the native libraries and the normal jars. Once complete it will automatically stage everything to Maven Central.
-
Monitor the GitHub Action release workflow and wait till it's complete.
-
Go to the Maven Central Deployments page and click "Publish".
-
Go to the newly created git tag and create a release for it. Have the release notes be auto-generated by 1) selecting the prior tag to compare with, and 2) clicking "Generate release notes". Add references to any new CVEs to the release notes. Important: Make sure that only 4.2.x releases gets marked with "Set as the latest release" — the 4.1.x series is no longer "latest".
-
Update the website, following the instructions below.
-
Create a new milestone for the next version, and close the old one. Move any outstanding issues and pull requests to the new milestone.
-
Publish any CVEs that were private until now.
-
Announce the release on various channels.
It is possible that some step in the process may fail.
- If the release was staged to Maven Central but was generated incorrectly, you can "Drop" it.
- If version update commits were generated and pushed to the repository, you can revert them.
- If a tag was created, you can delete it with
git push --delete <remote> <tagname>.
Then fix the release blocking issue and rerun the release process.
Our official web site is built with Awestruct. Please make sure you are familiar with Awestruct and its related markup languages such as HAML and Markdown.
If you did not yet, clone the web site project:
git clone [email protected]:netty/netty-website.git
cd netty-website
If you already have a check-out, make sure it's up to date:
cd netty-webstie
git checkout master
git pull
If you don't have Awestruct installed yet the easiest way to do so is to use bundler:
gem install bundler
After this is done ensure you have all dependencies installed by executing bundle in the netty-website directory.
This will take care of installing all the needed dependencies and Awestruct itself.
Note, if you don't want bundler to install the dependencies system-wide, you can tell it to keep them local to the netty-website directory by running bundle config set --local path .bundle inside the netty-website directory.
bundle
From the main netty/netty project directory, run the script to update the javadocs:
./scripts/generate_docs.sh ../netty-website netty-4.1.133.Final
The script takes a path to the netty-website check-out directory, and the newly released tag.
Commit the javadoc changes as a separate commit.
The _config/site.yml file contains important metadata about the latest Netty versions. For example, it has the following section:
releases:
- version: 5.0.0.Alpha5
date: 28-Sep-2022
stable: false
eol: false
- version: 4.2.13.Final
date: 04-May-2026
stable: true
eol: false
- version: 4.1.133.Final
date: 04-May-2026
stable: stable
eol: false
- version: 4.0.56.Final
date: 05-Feb-2018
stable: false
eol: true
- version: 3.10.6.Final
date: 29-Jun-2016
stable: false
eol: true
Update it with the new version number and release date.
After this add a new entry to the news/ folder which has the release details.
Make sure the file name does not contains a dot (.) or a whitespace (e.g. OK: 2014-07-04-4-1-0-Beta1-released.html.md NOT OK: 2014-07-04-4.1.0.Beta1-released.html.md
Try to generate the web site to confirm that the new version shows up in the generated web site.
This can done via:
bundle exec awestruct -d -u https://netty.io
Now you should be able to access the website via http://localhost:4242.
If everything looks like expected its time to commit the changes:
git add *
git commit -m "Release 4.1.133.Final"
git push
After this the website will be automatically build and deployed by a GitHub action.
TODO: Write me
The release procedure is fully automated via GitHub Actions. To start a release all you need to do is to run the GitHub Action release workflow. The workflow will take care of building all the native libraries and also the normal jars. Once complete it will automatically stage everything to the nexus staging repository and release it to central maven.
Nothing needs to be done manually, that said you may consider writing a release announcement and push it to the website.
The release procedure is fully automated via GitHub Actions. To start a release all you need to do is to run the GitHub Action release workflow. The workflow will take care of building all the native libraries and also the normal jars. Once complete it will automatically stage everything to the nexus staging repository and release it to central maven.
Nothing needs to be done manually, that said you may consider writing a release announcement and push it to the website.
The release procedure is fully automated via GitHub Actions. To start a release all you need to do is to run the GitHub Action release workflow. The workflow will take care of building all the native libraries and also the normal jars. Once complete it will automatically stage everything to the nexus staging repository and release it to central maven.
Nothing needs to be done manually, that said you may consider writing a release announcement and push it to the website.
The release procedure is currently a mix of executing a GitHub Action workflow and running a few scripts to finish the release process on macOS (64-bit). Install the required packages as well.
The release is mostly automated these days (and will be fully automated in the future hopefully). To start a release all you need to do is to run the GitHub Action release workflow. The workflow will take care of building all the native libraries and also the normal jars. Once complete it will automatically stage everything to the nexus staging repository. Monitor the GitHub Action release workflow and wait till it's complete.
Netty/Incubator/Codec/Quic releases must be done by using OpenJDK8 which can be downloaded from AdoptOpenJDK. Once downloaded and installed create a JAVA8_HOME env which points to the installation.
For example:
export JAVA8_HOME=/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home
Once this is done you are ready to finish the release.
First get the name of the current staged release (this release was staged by the GitHub workflow before).
./scripts/list_staged_release.sh
Now with this staging id you can run the script to finish the release. The script takes the staging id as first argument and the name of the tag as the second. So for example if you would try to finish the release of netty-incubator-codec-quic 0.0.13.Final you would run the following command:
./scripts/finish_release.sh ionetty-1398 netty-incubator-codec-quic-0.0.13.Final
Once the script completes the release of netty itself is done and it will be "promoted" to maven central.