Versioning

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

Version

abapGit follows semantic version 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

Changelog

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 list of the main branch.

Process

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_version and increase the minor version of constant c_abap_version by one. Example: '1.120.0' > '1.121.'.
3. Update changelog.txt 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 main.
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).