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 following CI jobs run successfully without any issue (the jobs include a full run of the test suite, which also covers regression testing) :

  1. narayana

  2. narayana-quickstarts

  3. narayana-AS_TESTS

• 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 Nexus.

• Ensure that Maven’s settings.xml includes the following profile:

  <settings>
    <profiles>
      <profile>
        <id>release</id>
        <activation>
          <property>
            <name>release</name>
          </property>
        </activation>
        <properties>
          <gpg.useagent>true</gpg.useagent>
          <gpg.keyname>...replace with your key's ID...</gpg.keyname>
        </properties>
      </profile>
    </profiles>
  </settings>

• Ensure that your .bashrc includes export GPG_TTY=$(tty) (.zshrc for MacOS)

  • Execute source ~/.bashrc in the terminal you will use to run the release script (source ~/.zshrc for MacOS)

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

Go to the directory where the Narayana repository is and run the script:

• 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

• When the narayana-release-process.sh script executes, Narayana artifacts are deployed to a private Nexus repository called narayana-staging

  • The community won’t be able to access the newly released version’s artifacts until they’ve been moved to the public Nexus repository, narayana

  • It’s essential to run the validation job before deploying new artifacts to the Nexus public repository. This step ensures that the artifacts meet all Maven Central requirements

    • If the validation job passes all checks, the new artifacts can be deployed to the narayana repository

      • cd ~/tmp/narayana/7.3.0.Final/sources/narayana

      • mvn nxrm3:staging-move -Dnexus.staging.tag=narayana-7.3.0.Final -DreleaseStaging

    • If the validation job didn’t pass all checks, the new artifacts can be deleted

      • cd ~/tmp/narayana/7.3.0.Final/sources/narayana

      • mvn nxrm3:staging-delete -Dnexus.staging.tag=narayana-7.3.0.Final -DreleaseStaging

  • After the artifacts have been moved to the narayana repository, the validation job for that repository must be executed

    • The validation job is expected to succeed, as the validation for narayana-staging has already passed

    • If that’s the case, execute the following commands to complete the release

      • cd ~/tmp/narayana/7.3.0.Final/sources/narayana/scripts

      • ./post-release.sh

• 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 a 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

  • NOTE: WildFly’s dependabot will never suggest minor or major version upgrades.

• 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 deployed to the server.

• 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"