Skip to main content


abapGitAbout 1 minread-first

abapGit is continuously developed and updated. The main branch always represents the latest development version and corresponds to the published standalone version.

abapGit does not have a predefined release cycle. However, we strive to tag a new version once a month (or two).


abapGit follows semantic versionopen in new window format. The community has settled on releasing enhancements and changes as minor versions. A more granular approach to releasing every change as a patch is adding too much overhead.

Example release sequence: 1.118.0 > 1.119.0 > 1.120.0


All additions, changes, fixes, and removals that are relevant to abapGit users are listed in the changelog.

Reorgs, refactoring, or changes related to testing or repo actions are omitted from the changelog.

Since abapGit is enforcing a linear history, you can find all changes in commit listopen in new window of the main branch.


The following steps need to be taken to create a new abapGit version:

  1. Create a new branch name like the new version. For example, v1.121.0.
  2. Update zif_abapgit_versionopen in new window and increase the minor version of constant c_abap_version by one. Example: '1.120.0' > '1.121.'.
  3. Update changelog.txtopen in new window and add a section at the top for the new version.
  4. Compile a list of the relevant pull requests (see above) based on a comparison between the most recent tag and main. For example, v1.123.0 vs mainopen in new window.
  5. Label each change (PR) corresponding to the legend (*: fixed, !: changed, +: added, -: removed).
  6. Create a new, draft pull request from the new branch.
  7. Have the changes reviewed by someone else.
  8. On the release day, update the date in the changelog, and merge the pull request.

The merge will trigger a GitHub action to automatically tag the new release and perform some downstream tasks (like updating the build repository).