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 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
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.
The following steps need to be taken to create a new abapGit version:
- Create a new branch name like the new version. For example,
zif_abapgit_versionand increase the minor version of constant
c_abap_versionby one. Example:
'1.120.0' > '1.121.'.
changelog.txtand add a section at the top for the new version.
- Compile a list of the relevant pull requests (see above) based on a comparison between the most recent tag and
main. For example,
- Label each change (PR) corresponding to the legend (
- Create a new, draft pull request from the new branch.
- Have the changes reviewed by someone else.
- 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