Release Manual 10.2.x Release 10.2.1 Release 10.2.1 includes these notable new features:

  • Plugins are now stored in a database, not in the file system
  • The Plugin Manager supports cluster installations
  • GitOps-enabled version control is available in Tech Preview
  • NTLM support for proxies
  • Webhook event tasks
  • Stability and performance improvements

The complete list of improvements and bug fixes are described below.

Support Policy’s support policy has changed from the previous Long-Term Support (LTS) and Short-Term Support (STS) policies to a simplified single policy. Product versions are now supported for one year following their release, with an additional three months after the end of that year available to ask questions of support. 

For more details, please see Support Policy.

Upgrade Instructions

See below for upgrade notes specific to this version. For detailed instructions on upgrading from earlier versions of Release, refer to Upgrade scenarios.

IMPORTANT Starting with release 10.2.1, plugins are stored in a database and no longer managed by moving files to different locations in the filesystem. This has implications for upgrading the product and installing and upgrading plugins. See below for more information.

Feature breakdown and version-specific upgrade instructions

Plugin Manager

The new Plugin Manager improves the tasks of installing and upgrading integration plugins. Refer to Plugin Manager for more information.

The following are changes to how plugins are installed and loaded by the system:

  • Plugins are no longer installed by copying files into directories – they should be installed by using the Plugin Manager UI
  • The Plugin Manager UI is available in cluster mode and plugins are automatically distributed across nodes
  • Plugin directories on the server are managed by the Plugin Manager and should not be manipulated by hand.

Additional issues:

  • The hotfix directory is now split into hotfix/lib and hotfix/plugins
  • hotfix and ext directories are not managed by the Plugin Manager, and you must managed them manually
  • After installing or upgrading a plugin, you must restart all your servers
  • When installing a product upgrade, a new version of bundled plugins are automatically uploaded to the plugin database.

IMPORTANT Classpath entries for plugins have been removed from xlr-wrapper-linux.conf and xlr-wrapper-windows.conf. When using either the automated or manual procedure, you MUST manually edit these files to remove the plugins entry from the classpath. If you have custom entries in the wrapper files please make sure to not include any folders that contain plugins and plugin hotfixes.

If the product won’t start and issues an error message that duplicate plugins are detected, you probably need to update the wrapper.conf file.

Troubleshooting with the Plugin Manager CLI

The Plugin Manager downloads plugin files from the database and places them into the file system of a server node. In case of misconfiguration, plugins can be deleted from the database by invoking the Plugin Manager CLI from the command line:

$ bin/

GitOps-enabled Version Control (Tech Preview)

GitOps-enabled version control brings the GitOps style of authoring, reviewing, and publishing content backed by version control to the Release UI.

This feature allows you to version and publish any folder content from the UI – templates, variables, shared configuration, etc. – and share it across folders and even separate Release instances. Internally, YAML code is stored in Git and therefore integrates seamlessly with code-centric workflows.

This feature is in Tech Preview for evaluation purposes and can be enabled in Feature settings.

For more information, refer to GitOps-enabled version control.

NTLM Proxy Authentication

The proxy configuration for HTTP servers now supports the NTLM authentication protocol.

This feature is available for the following plugins:

  • Agility plugin
  • BlackDuck plugin
  • CheckMarx plugin
  • SonarQube plugin
  • ServiceNow plugin
  • Octopus Deploy plugin
  • SonarCloud plugin
  • Git plugin
  • Jenkins plugin
  • Jira plugin
  • Nexus plugin
  • Fortify on Demand plugin

Webhook Event Tasks

The new Webhook event tasks feature makes it possible to listen passively (without polling) for outside events received on HTTP Endpoints for Webhooks.

The bundled task Webhook: Wait For Json Event allows you to listen for events and process them with scripts. It uses the same event mechanism as Webhook triggers.

It is also possible to create custom webhook tasks in a plugin. In synthetic.xml, extend the task type webhook.ReactiveTask to create a new webhook event task type and tailor it to your needs. This can eliminate the need for polling and requires the Release server to be reachable from the third-party webhook source.

For more information, please refer to Webhook event tasks.

Release with Delivery Insights

The Delivery Insights dashboard presents the Manifest View for individual application versions and for individual phases. The Manifest View lets you know more about the work items that are part of:

  • an application version in a phase
  • all the application versions in a phase

The Manifest View includes the following work item information:

  • work item ID
  • work item title
  • work item type
  • application, which the work item belongs to
  • date and time of last activity
  • status of the work item
  • and the number of changes (commits) in the work item

You can also download the manifest for a phase or a version (as a .csv file).

  • To view the Manifest View for a phase, click Manifest view next to the phase name in the Delivery Insights dashboard.


  • To view the Manifest View for an application’s version, click Manifest view on the application version’s card in the Delivery Insights dashboard.


In addition, a new Commits tab has been added to the Work Item Details Pane that shows the list of commits associated with the work item.

commits history tab

Stability and Performance Improvements

Many changes have been made to improve the stability and performance of the Release server in this release. Most notable is the task execution scheduler’s use of the database, making the system more resilient in multi-node setups.

OIDC Public Client Support

Support has been added for configuring public clients with OIDC in xl-release.conf.

If clientAuthMethod is set to ‘none’, the Release server will act as public client. Then clientSecret will not be required and can be removed from the configuration.

The property redirectUri is now optional and will be derived from the server.url property in the xl-release-server.conf file. If needed, it can still be overridden in the OIDC configuration.

xl {
  security {
    auth {
      providers {
        oidc {
          clientAuthMethod = "none"
          clientSecret = <not required now if clientAuthMethod is set as none>
          redirectUri = <optional and will be derived from server.url>

Other Configuration Changes

Remember-me token validity can now be configured, the default value is 30 days. For example:

xl {
    server {
        session {
            remember-me {
                tokenValidity = 30 days

Other Support Release v.10.2.1 is the last release that supports Internet Explorer 11. Release Integrations


Users can now specify build versions with Create Release Task.

Agility Integration Plugin

  • Using the Update Multiple Asset Status task one can now update multiple assets status for the following similar types:
  • Defect
  • Test
  • Task
  • Story
  • Functionality has been added to show the Asset Number and Token from the Data section in Output properties for the following tasks:
  • Check Issue
  • Create Asset
  • Create Issue
  • Update Multiple Asset Status

Hashicorp Vault Plugin

Output properties of ReadSecret now optionally display password variables. Release 10.2.1 Bug Fixes

Bug fixes

  • [ENG-3831] - Fixed the As-code issue while exporting the tasks with slash ”/” on name, which results in”/”
  • [ENG-5152] - Fixed the setofstring field which used to lost when the template is applied/created through the CLI
  • [ENG-5200] - Updated the user interface with the more precise format for Day, Week, and Month
  • [ENG-5254] - Fixed: The same object (variable) value is modified from different threads
  • [ENG-5345] - Find or Create Delivery task—Fixed an issue that prevented users from viewing the Pattern/Stage information on Find Or Create Delivery tasks.
  • [ENG-5409] - Fixed: Create Release task displays ReleaseId instead of Release Title
  • [ENG-5464] - Fixed to pass multiline string parameter in Jenkins task
  • [ENG-5508] - Fixed the server not shutdown issue via API
  • [ENG-5631] - Fixed an issue that prevented Trigger creation when you import and apply an As Code YAML file that defines:

    • a Release Template and a time-based Trigger—wherein the template’s name starts with “Release” and the trigger references this template
    • a Release Template and an event-based Trigger—wherein the template’s name starts with “Release” and the trigger references this template
  • [ENG-5634] - Fixed: Password handling in script tasks is inconsistent when override of security is used
  • [ENG-5719] - Fixed an issue that prevented the user from exporting the Release Audit Report.
  • [ENG-5840] - Fixed the Password field when becomes blank while starting release from Create Releaser task
  • [ENG-6420] - Updated and fixed the ‘User Input’ task detail view UI from two inputs to one and variable field to show the previously added value
  • [ENG-6618] - Fixed the issue: ‘Create Release’ task displays the release ID instead of title for the Root level template Release 10.2.2

Kubernetes Operator-based Installation

Note: Helm Charts-based installer is no longer available for Release 10.2 and later.

  • Release 10.2.2 brings you a simple and sophisticated Kubernetes Operator-based installer to install Release on Amazon EKS, Azure AKS, and OpenShift on AWS clusters
  • You can download the new Kubernetes Operator-based installer from the Deploy/Release Software Distribution site
  • Once you download the installer Zip file, Release installation is as simple as adding a few configuration parameters and custom resource definitions to the installer files and running the installer

For more information about Kubernetes Operator-based installation, see Kubernetes Operator. Release 10.2.2 Bug Fixes

Bug fixes

  • [ENG-5504] - Fixed the issue when a large number of environments are present, Deployment tile throws an exception
  • [ENG-7024] - Fixed the duplicate TaskPreconditionValidated deliveries by clearing the executionId on task.
  • [ENG-7072] - Fixed the issue of variables with DOT in the name, which is not supported when webhook events trigger. Release 10.2.3

Kubernetes Operator-based Installation

With Release 10.2.3, the Kubernetes Operator offers the following enhancements:

Bug fixes

  • [ENG-7296] - Fixed the As Code Apply failure issue for Custom Script task when the Synthetic Property is set as Empty.
  • [ENG-7282] - Fixed Trigger failure that caused serialization error in cluster mode.
  • [ENG-7186] - Fixed the issue where RolesApi#getRole()property did not return the exact role name.
  • [ENG-7175] - Increased release column width on release groups.