> ## Documentation Index
> Fetch the complete documentation index at: https://agenticbanking.backbase.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Release process

> Understand how Grand Central APIs, connectors, SDKs, and Maven BOMs are released and governed.

This page is for implementation teams that develop and release Grand Central
API specifications, connectors, and SDKs. These teams include Backbase,
customer, and partner engineers. If you build on Grand Central, use this page
as the reference for versioning, compatibility, release procedures, and
publication controls.

The page describes the release agreement that the Platform team and
implementation teams follow. The Platform team owns the shared delivery
foundation, including repository templates, reusable workflows, Platform
SDKs, and Maven Bill of Materials (BOM) files. Ecosystems teams are the
Backbase implementation teams that own API specifications and connectors.
When customer or partner teams develop their own API specifications or
connectors, the responsibilities described for Ecosystems teams apply to them
too.

Grand Central OpenAPI specifications, connectors, SDKs, and Maven BOM
artifacts have independent release lifecycles. Unified GitHub workflows
provide common release automation without coupling the release schedules of
these artifacts.

This model lets Ecosystems teams release an API specification or connector
when the artifact is ready. Platform libraries and build tools follow their
own release schedules.

## Release model

Each Grand Central artifact uses Semantic Versioning (SemVer). A connector
implements exactly one API specification. Multiple connectors can implement
the same API specification.

An API release doesn't trigger a connector release. A connector release
doesn't trigger an API release. The connector and its API specification must
have the same major version. Pull request validation enforces this
compatibility rule.

For example, a connector with major version `2` must implement an API
specification with major version `2`. The minor and patch versions can differ
because each artifact evolves independently.

<Info>
  The `grandcentral-api-bom` artifact groups independently released API
  versions under a calendar version. This logical grouping doesn't create an
  API release train or change the SemVer version of an API specification.
</Info>

The following table shows the ownership, version model, and release output for
each artifact type.

| Artifact | Owner | Version model | Main release outputs |
| :- | :- | :- | :- |
| API specification | Ecosystems implementation team | SemVer | Maven JAR, OpenAPI YAML file, Helm chart, and software bill of materials |
| Connector | Ecosystems implementation team | SemVer | Container image, Helm chart, and software bill of materials |
| Platform SDK or library | Platform team | SemVer | Maven JAR and software bill of materials |
| Vendor-specific SDK or library | Ecosystems implementation team | SemVer | Maven JAR and software bill of materials |
| `grandcentral-bom` | Platform team | SemVer | Maven parent POM with Platform dependencies, SDKs, plugins, and default plugin configuration |
| `grandcentral-platform-bom` | Platform team | SemVer | Maven BOM with compatible, Platform-tested core dependency versions |
| `grandcentral-api-bom` | Ecosystems senior API engineers | Calendar Versioning (CalVer) | Logical catalog of independently released API versions |

## Common release lifecycle

The repository templates use the following branches:

* `develop` contains integrated changes for the next release.
* `main` represents the active major release line.
* `release/*` maintains an earlier supported major release line.
* `feature/*` branches start from `develop`.
* `hotfix/*` branches start from `main` or the relevant `release/*` branch.

The following diagram shows the common lifecycle for an API specification,
connector, SDK, or Platform BOM:

```mermaid theme={"system"}
%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryBorderColor': '#295eff',
    'primaryTextColor': '#091c35',
    'lineColor': '#091c35',
    'secondaryColor': '#f3f6f9',
    'tertiaryColor': '#ebf0f5',
    'fontFamily': 'Libre Franklin, sans-serif'
  }
}}%%
graph TD
    Feature[Develop on a feature branch] --> PullRequest[Open a pull request]
    PullRequest --> Validation[Run validation and security checks]
    Validation --> MergeDevelop[Merge into develop]
    MergeDevelop --> Snapshot[Publish a snapshot]
    Snapshot --> ReleaseDraft[Create a release draft]
    ReleaseDraft --> PublishRelease[Review and publish the release]
    PublishRelease --> ReleaseArtifacts[Publish release artifacts]
    PublishRelease --> MergeBack[Merge the version update into develop]
    Hotfix[Develop a hotfix]
    MaintenancePR[Merge into main or release branch]
    Hotfix --> MaintenancePR
    MaintenancePR --> ReleaseDraft
```

The branch filters and triggers live in each artifact repository. The reusable
workflows provide the shared validation, version resolution, build, and
publication steps.

### Create a planned release

To release integrated changes from `develop`:

1. Confirm that the required changes are merged into `develop`.
2. Run the repository's **Create new release draft** workflow.
3. Review the generated tag, the GitHub release draft, and the release notes
   generated from pull requests.
4. Publish the GitHub release.
5. Merge the generated version-update pull request from `main` into `develop`.

The release-draft automation verifies the Maven project, removes the
`-SNAPSHOT` suffix, creates an annotated SemVer tag, and creates the GitHub
release draft. It then increments the patch version on `main` and opens the
merge-back pull request.

Publishing the GitHub release starts the artifact-specific release workflow.
The release workflow builds from the tag and publishes immutable release
artifacts.

### Create a maintenance release

If a supported major version needs a fix:

1. Create a `hotfix/*` branch from `main` or the relevant `release/*` branch.
2. Open and merge a pull request into the same release line.
3. Review the release draft that the merge creates.
4. Publish the GitHub release.
5. If the target is `main`, merge the generated version-update pull request
   into `develop`.

A maintenance release from a `release/*` branch stays on that release line.
The branch structure doesn't define how long a major version receives support.

## API specification releases

Ecosystems implementation teams develop and release API specifications. Each
API repository contains one logical OpenAPI specification and uses its Maven
project version as the source of truth. The release tag, JAR version, and
OpenAPI `info.version` use the same SemVer value.

Pull request checks validate the OpenAPI specification and check backward
compatibility. Breaking changes require a major version change. The API and
its connector implementations remain on independent release schedules.

API workflows publish the following artifacts:

* A Maven JAR containing the bundled OpenAPI YAML file
* The bundled OpenAPI YAML file as a GitHub release asset
* A Helm chart that represents the API for Azure API Management (APIM)
* A software bill of materials for vulnerability monitoring and API catalog integration

Snapshot and release builds publish the Maven JAR to GitHub Packages.
Release workflows also publish the JAR and YAML file to Backbase Artifactory.

Snapshot workflows publish the API Helm chart to the installation Azure
Container Registry (ACR). Release workflows promote the chart to the Enterprise ACR.

The chart installs an API custom resource based on a Custom Resource Definition (CRD)
supported by Azure Service Operator. Installing the chart promotes
the specification to the APIM API gateway.

For more information about API deployment, see
[Configure APIM](/platform/developer-guides/get-started/configuring-apim).

### Unified API calendar releases

The `grandcentral-api-bom` repository lists selected versions of independently
released API specifications. Ecosystems senior API engineers maintain this repository.

Merging a release change into its `main` branch creates a published CalVer
release and publishes the API BOM. The CalVer value provides a calendar-based
view of the API catalog for Backbase consumers. It doesn't alter, rebuild, or
release the referenced API specifications.

For the contents of each calendar release, see
[Unified API release notes](/release-notes/unified-apis).

## Connector releases

Ecosystems implementation teams develop and release connectors. A connector
repository declares the API specification that the connector implements.
Pull request checks compare the connector major version with the declared API
major version.

Snapshot and release workflows build a container image and Helm chart.
Snapshot artifacts go to the installation ACR. Release artifacts go to the
Enterprise ACR after the release gate passes.

The connector lifecycle remains independent of its API lifecycle. If an API
publishes a compatible minor or patch release, each connector team decides
when to adopt that version. If an API changes its major version, a connector
team updates the connector major version when the implementation adopts that
API contract.

## Platform SDK and library releases

The Platform team owns and releases the Grand Central SDKs and supporting
libraries. These artifacts include:

* The `grandcentral-connectors-sdk` Maven library
* The `grandcentral-platform-kamelets` Maven library
* Maven plugins that provide build, validation, packaging, and delivery support

Each library uses SemVer independently. A version change communicates
compatibility to clients of that library. Snapshot JARs support development
and validation. Snapshot and release builds publish JARs to GitHub Packages.
Publishing a GitHub release also publishes the release JAR to Backbase
Artifactory.

An SDK release doesn't trigger an API or connector release. Ecosystems teams
adopt a released SDK version through a normal dependency or BOM update.

## Maven BOM releases

The Platform team maintains two Platform BOMs:

* `grandcentral-platform-bom` defines compatible, Platform-tested versions of
  core dependencies.
* `grandcentral-bom` provides versions for Platform dependencies, SDKs, and
  Maven plugins. It also provides default Maven plugin configurations to
  reduce boilerplate in connector repositories.

Both BOMs have independent SemVer releases. Updating a version in a BOM
selects an already released dependency. The BOM release doesn't release or
rebuild that dependency.

Snapshot and release builds publish the BOM POM to GitHub Packages. Publishing
a GitHub release also publishes the release POM to Backbase Artifactory.

Ecosystems teams adopt a `grandcentral-bom` release by updating the Maven
parent version in a connector repository. This explicit update keeps the
connector release independent of the Platform BOM release.

The `grandcentral-api-bom` has a different purpose. It provides the logical
CalVer API catalog and doesn't provide the Platform dependency baseline for
connector builds.

## Security and software bills of materials

API, connector, and SDK pipelines create software bills of materials (SBOMs).
Pull request and release workflows run Trivy vulnerability scans for these
artifact types.

Release workflows publish SBOMs to DependencyTrack. DependencyTrack
continuously checks the released component inventory for known
vulnerabilities after publication.

The Backbase catalog also uses API SBOMs to identify API specifications that
are available to customers. The Ecosystems-owned `grandcentral-api-bom`
repository enforces the API catalog and SBOM integration for its CalVer
release.

For more information about development controls, see
[Security architecture](/platform/security).

## Ownership and enforcement

The Platform team owns the shared delivery foundation:

* GitHub repository templates for APIs and connectors
* Unified GitHub workflows and actions
* The `.github/` directory controls in implementation repositories
* Platform SDKs, Kamelets, and Maven plugins
* `grandcentral-bom` and `grandcentral-platform-bom`

The Platform team remains a code owner for the `.github/` directory in each
Grand Central implementation repository, including customer and partner
repositories. This ownership helps enforce security and compliance changes to
workflow definitions.

Ecosystems implementation teams own API and connector code, version changes,
release timing, and release publication. Ecosystems senior API engineers also
maintain `grandcentral-api-bom`.

Unified GitHub workflows provide the following controls:

* Maven version resolution and snapshot naming
* Pull request validation and API-to-connector major version checks
* Trivy vulnerability scanning and SBOM publication
* Artifact builds and publication to Maven repositories and ACRs
* Release draft, tag, and merge-back automation

Each repository still defines when a reusable workflow runs, which workflow
revision it uses, and which branch protections and reviewers apply.

## Related topics

* [Grand Central iPaaS architecture](/platform/architecture)
* [API playground](/grand-central-apis/api-playground)
* [Run a connector](/platform/developer-guides/run)
* [Repository structure](/platform/platform-administration/repository-structure)