Skip to main content
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.
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.
The following table shows the ownership, version model, and release output for each artifact type.

​
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: 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.

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

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

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