-
Notifications
You must be signed in to change notification settings - Fork 176
Narayana Release Process
This page provides all instructions to release Narayana from its main
branch.
ℹ️
|
Older versions of Narayana have a slightly different release procedure; further info can be found at developer.jboss.org. Moreover, some info are reported here as well:
|
The Narayana release procedure is semi-automated. It’s expected to be run "manually" on a local machine. Most steps are automatised by the shell script narayana-release-process.sh. Narayana is always released from the main branch.
|
To release Narayana, access to Red Hat’s internal systems is needed (e.g. VPN connected, permissions for jboss nexus, etc.). |
The local environment where the release will take place has to satisfy several prerequisites.
-
There should not be any issue tracker in the JBTM project with priority
blocker
-
Use the following query to check this requisite
project = JBTM AND priority = Blocker AND resolution = Unresolved
-
In case there are blockers, discuss them with the team
-
-
Ensure the Narayana CI job runs successfully without any issue (the job includes a full run of the test suite, which also covers regression testing)
-
Ensure that JDK17 or higher (
java -version
) is used -
Ensure
$JAVA_HOME
is set up (it is needed for the idlj generation) -
Ensure that the user running the release script has permissions to push Narayana’s artifacts to https://repository.jboss.org/nexus
-
Maven’s
settings.xml
should have the credentials defined for jboss nexus -
To do so, the server with id
jboss-releases-repository
should be defined in~/.m2/settings.xml
<settings> <servers> <server> <id>jboss-releases-repository</id> <username>[username for jboss nexus connection]</username> <! e.g. [email protected] --> <password>[token for jboss nexus connection]</password> </server> </servers> </settings>
-
username
andtoken
can be obtained through the Red Hat’s Token Generator (the user should log in)
-
-
The Narayana’s code base directory where the release will take place should present a git repository with a
remote
namedupstream
-
When cloning the repository from scratch, run the following command
git clone https://github.com/jbosstm/narayana.git -o upstream narayana-release
-
When using an existing repository, run the following command:
git remote add upstream https://github.com/jbosstm/narayana.git; git fetch upstream; git reset --hard upstream/main
-
-
The
narayana-release-process.sh
script requires the existence of the directory~/tmp
(usemkdir -p $HOME/tmp
before running the script)⚠️ Ensure you do not have or need a ~/tmp/narayana
before executing the release process as the release process uses that directory for its own purpose (remove~/tmp/narayana
before running the script)
Go to the directory where the Narayana repository is and run the script:
# cd $PWD/narayana-release
./narayana-release-process.sh 5.10.6.Final 5.10.7.Final
-
5.10.6.Final
is the release to be done (most likely the version declared in thepom.xml
file withoutSNAPSHOT
, e.g.5.10.6.Final-SNAPSHOT
) -
The new version will be used to update all
pom.xml
files in the code base, e.g.5.10.7.Final-SNAPSHOT
-
-
Create a new release version in the JBTM project’s home page
-
In the home page of the JBTM project, open Releases in the sidebar
-
Add the new release (e.g.
7.2.0.Final
) using the textboxes at the top of the page (e.g.7.2.0.Final
with release date and a short description)
-
-
The
fixed version
field (e.g.7.next
) should be adjusted to the just-released Narayana’s version (e.g.7.2.0.Final
)-
Check which JBTMs are grouped with the current fixed versions (e.g.
7.next
) -
Using the following query:
project = JBTM AND fixVersion IN (7.next,7.later) AND status != Closed AND resolution != Unresolved
fetch all JBTMs that are part of the just-released Narayana’s version
-
Go to top right corner to
Tools
and selectBulk Change
-
Check that the list of all JBTMs that should be included in the bulk action is correct and select all relevant JBTMs
ℹ️Among these JBTMs there could be some issues tracker with a
Resolution
not equal toDone
:-
In case the
Resolution
is incorrect, fix it -
In case the
Resolution
is correct (e.g.won’t fix
orcannot reproduce
) but a PR linked to the issue tracker has been merged, do not worry: the issue/PR introduced something in Narayana’s code base (e.g. a test, a comment, etc.) thus the issue tracker should be mentioned in the just-released Narayana’s version
-
-
Select
Edit Issues
-
Modified the
Fixed Version
accordingly to your needs (usually, it is just a matter of replacing thex.next
label with the version just released)
-
-
At last, close all JBTMs
-
Using the following query:
project = JBTM AND fixVersion IN (7.2.0.Final) AND status != Closed AND resolution != Unresolved
fetch all JBTMs that are part of the just-released Narayana’s version
-
Go to top right corner to
Tools
and selectBulk Change
-
Select all relevant JBTMs
-
Transition all JBTMs to
Closed
-
-
Eventually, release the new Narayana’s version through the Releases page
-
-
Once the new Narayana’s version has been marked as released, copy the link of its
Release Notes
(click on the desired version → at the top of the page there is a link to "Release Notes") -
Create a new WildFly issue to update the version of Narayana in WildFly
-
Past examples can be query:
project = WFLY AND text~"Upgrade Narayana" ORDER BY created DESC
-
Select the 'Fix Version/s' and Priority (if appropriate).
-
Link it as "blocks" to any open WFLY issues that are resolved/alleviated with the new Narayana release
-
Open PR for WildFly, when possible it is recommended to create a branch (with the name of the WFLY issue) from the jboss-as project (https://github.com/jbosstm/jboss-as) and open the PR against wildfly main. This is a more open and collaborative way as more than one collaborator can work on the PR.
-
Add a description to Wildfly issue (e.g. https://issues.redhat.com/browse/WFLY-19470), for example:
-
tag link
-
diff link (github)
-
and release notes link
-
-
-
A PR for Quarkus is automatically opened by the dependabot (checking the PR is good)
-
As part of the release process, a new version of the website https://narayana.io should be published. The page will be built locally and then deplyed to the server.
|
The following steps do not apply to ../wiki/Creating-a-maintenance-branch[maintenance branches]. |
-
Check that the quickstarts work with the artifacts that have been deployed to Maven central and also obtain the performance numbers for the release for publishing
-
This action can be achieved through the CI
-
-
Verify that all jobs in the CI view passed (if they fail the release can be considered as finished just wisely decide)
-
Email [email protected] modifying this text:
subject:Narayana <VERSION>.Final is released Hello, The Narayana team are proud to announce the release of version <VERSION>.Final of Narayana! The maven artifacts for the release are available at maven central. << (Optional) Description of the main achievements of this release >> Tag: https://github.com/jbosstm/narayana/releases/tag/<VERSION>.Final Diff: https://github.com/jbosstm/narayana/compare/<PREVIOUS_VERSION>.Final...<VERSION>.Final The release notes for this version are available from: https:https://issues.redhat.com/secure/ReleaseNote.jspa?projectId=.... Happy coding, The Narayana team
-
NOTE: If you don’t immediately see the message in the archive, it is very likely that it needs to be approved
-
-
Send the same message to Narayana google group to inform the community that a new version of Narayana was released
-
Announce that ‘Narayana x.x.x.Final` is available on Zulip
-
Consider publishing a tweet at narayana_io like: "Narayana https://lists.jboss.org/archives/list/[email protected]/thread/6H4I5KPSPIW7LGGLPVS7K2D4D74Q74UH/ released - find out more at https://lists.jboss.org/archives/list/[email protected]/thread/6H4I5KPSPIW7LGGLPVS7K2D4D74Q74UH/ #narayanaio"
-
cd $HOME/tmp && git clone [email protected]:$USER/narayana.io.git
-
rm -rf $HOME/tmp/narayana.io/content/en/docs/api; cp -r $HOME/tmp/narayana/$VERSION/sources/narayana/narayana-full/target/site/apidocs $HOME/tmp/narayana.io/content/en/docs/api
rm -rf $HOME/tmp/narayana.io/content/en/docs/project && rm -rf $HOME/tmp/narayana.io/content/en/docs/product; cp -r $HOME/tmp/narayana/$VERSION/sources/documentation/target/html/* $HOME/tmp/narayana.io/content/en/docs/
-
Update the download page with the latest release version
-
(e.g. on macOS)
sed -i '' 's/7\.2\.0/7\.3\.0/g' "_index.md"
-
-
Commit and push the updated website to github and then open a PR
-
Upload artifacts from CI (see the guide https://github.com/jbosstm/artifacts): e.g https://github.com/jbosstm/artifacts/pull/28
-
The prerequisites are the same as for main branch. The post action consists only releasing the version in jira while placing the correct issues to the release.
The 5.11 release contains
-
release tag
-
uploads artifacts to downloads (http://www.jboss.org/jbosstm/downloads/)
-
JIRA version maintenance like in
Release of Narayana main branch
The 5.11 release omits
-
creating a PR with component upgrade to WildFly linking the WFLY issue
-
creating and uploading the LRA coordinator docker image
-
building and changing the content of the http://narayana.io website
The prerequisites are the same as for main branch. The post action consists only releasing the version in jira while placing the correct issues to the release.
The 6.0 maintenance branch releases contain
-
release tag
-
although we do not release the quickstarts there is a requirement to tag the repo (with the same release tag used for the main repo maintenance branch)
-
JIRA version maintenance like in
Release of Narayana main branch
The 6.0 release omits
-
creating a PR with component upgrade to WildFly linking the WFLY issue
-
releasing the quickstarts (although a tag is required)
-
creating and uploading the LRA coordinator docker image
-
building and changing the content of the http://narayana.io website
The prerequisites are the same as for main branch. The post action consists only releasing the version in jira while placing the correct issues to the release.
The 7.1 maintenance branch releases contain
-
release tag
-
although we do not release the quickstarts there is a requirement to tag the repo (with the same release tag used for the main repo maintenance branch)
-
JIRA version maintenance like in
Release of Narayana main branch
The 7.1 release omits
-
creating a PR with component upgrade to WildFly linking the WFLY issue
-
releasing the quickstarts (although a tag is required)
-
creating and uploading the LRA coordinator docker image
-
building and changing the content of the http://narayana.io website