## 4.2.14.1.5.5.2  Build the First Add-On Version
## Create Maintenance Branch
##  Recommendation
For each release and support package level, as an add-on admin, create a maintenance branch that is used for development of bug fixes and maintenance deliveries. See Versioning and Branches [page 1204].
In test system TST, create branch v1.0.0 that is based on the main branch.
## Create API Snapshot
In case of released APIs, create and generate a new API snapshot, e.g. v1.0.0, for the new release in test system TST and the development system DEV. Set the new API snapshot as check-relevant so that it will be used as a reference for API compatibility checks after implementation of the initial version. Refer to Manage API Snapshots.
##  Note
Currently API snapshots need to be generated locally per system. Therefore, be careful to not release new APIs between the maintenance branch and snapshot creation. Refer to Released APIs and Snapshots.
The API snapshots in the correction system COR and quality assurance system QAS will be created once the maintenance branch is checked out for the first time, usually during the first patch version creation.
## Build New Product Version
Each version contains an add-on version number - 1.0.0 for the initial delivery - as well as the included software components, such as the corresponding names, branches, and software component versions to be used for the add-on build. You may also choose specific software component commit IDs (as seen in the
Manage Software Components app) and select which languages should be included in the new product version. Add-on version numbers may not be used more than once.
## Build Using Product Version App (recommended)
New product versions for your registered add-on products can be de ned directly in the Build Product Version app. The initial product version will always be of type 'Release Delivery' . See Create a New Product Version.
The corresponding pipeline is executed automatically when the Build Product Version button is clicked on in the app. If the execution is successful, the initial version of the add-on will then be available for installation.
## Build Using Manual Configuration
If using a custom pipeline configuration and your own Jenkins server, create an add-on configuration file ( addon.yml ) in the corresponding Git repository. This file includes the metadata of the add-on product that is being built, such as versioning information and the included software component versions. Please follow the best practices on how to define the addon.yml file. See Add-on Descriptor File .
Once the repository is updated, trigger the pipeline execution on your Jenkins server. If your pipeline includes manual confirmation steps, you will have to follow its progress and react accordingly. You may use the add-on installation test system ATI to confirm the success of the add-on installation before confirming its release. You can also use the system for additional tests, similar to the steps described in Test in the ABAP Environment SAP Fiori Launchpad. For testing in a consumer-like environment, you can create tenants of type Test Tenant using the Landscape Portal application. See Use Test Tenants.
##  Tip
For in-depth information about versioning and branches, check out Versioning and Branches [page 1204].
To learn how software lifecycle management in the ABAP environment works with software components, see Basic Concepts and Terms [page 757].
##  Note
Please make sure that the add-on product version to be published is properly tested before confirming the release decision. This includes testing in SAP Fiori launchpad and the ABAP Test Cockpit. See Test in the ABAP Environment SAP Fiori Launchpad [page 1236] and Test in the ABAP Test Cockpit [page 1238].
During add-on build a new semantic version API snapshot will be automatically created for each add-on software component. In the assembly system BLD semantic version snapshots are automatically created and set to check-relevant during add-on build. Do not perform manual actions on API snapshots in such systems. For the initial software component version 1.0.0 no predecessor version is available and thus compatibility checks will not be performed due to the missing API snapshot. See Released APIs and API Snapshots.
## Check Add-on Build Result
Use the Check Product Version app in Landscape Portal to check whether the product version, its components, and respective packages are ready for delivery. See Check Product Version.