Skip to content

Narayana Release Process

Marco Sappé Griot edited this page Mar 14, 2025 · 48 revisions

Narayana release procedure

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:

Intro

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.).

Release of Narayana main branch

Prerequisites

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 and token 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 named upstream

    • 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 (use mkdir -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)

Execute the release 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 the pom.xml file without SNAPSHOT, 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

Post release actions

  • JIRA

    • 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 select Bulk 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 to Done:

        • In case the Resolution is incorrect, fix it

        • In case the Resolution is correct (e.g. won’t fix or cannot 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 the x.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 select Bulk 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"

Update website

  1. cd $HOME/tmp && git clone [email protected]:$USER/narayana.io.git

  2. 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/

  3. 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"

  4. Commit and push the updated website to github and then open a PR

Release Narayana 5.11 branch

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

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

Release Narayana 6.0 branch

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

Release Narayana 7.1 branch

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