SAP
Strategy for the 7.58 branch
Dear SAP, what's the strategy regarding the branch SAP_BASIS-7.58-compatible? How do you expect contributions to main to reach the branch? How do you expect contributions to it to reach main? I also noticed the branch only has 9 ATC checks so far and hasn't been updated for two years.
Please explain - thank you 🙂
The original idea was that generally every contribution to main (except documentation changes, since we link only the documents from the main branch everywhere) should be evaluated whether it is compatible with SAP_BASIS 7.58, and if it is, the corresponding change backported also to the SAP_BASIS-7.58-compatible branch.
The only other commits that should be made on the compatibility branch(es) are bug fixes that are irrelevant for main because the bug no longer occurs there due to other non-backportable changes.
As it turns out, almost all contributions in the last years have relied on functionality that is not present in SAP_BASIS 7.58. This is not really a surprise, to be honest, since SAP co-evolved the released API to write ATC checks in ABAP Cloud by writing more Code Pal checks and then adding features to the API that these checks required. That's also the reason there are fewer checks in there - if you tried to install the missing in a 7.58 system, you would get syntax errors, and there is (while staying within the ABAP Cloud language version) no workaround for the missing functionality.
If a future commit uses functionality not available in SAP_BASIS 8.16 (corresponding to the recent 2025 on-premise release), there will also be a SAP_BASIS-8.16-compatible branch created from the last commit before it.
The main goal of the compatibility branches is to provide users who installed the (at the time current) version of main in their on-premise system with something they can continue to use if they need to set up systems on the same (now older) release, since pulling the current version of main would lead to syntax errors. We use a separate branch and not just a release tag or something like that to leave open the option to provide bug fixes as mentioned above, but it is not the goal that the compatibility branch receive back-ported versions of all functionality from main (which would be impossible while staying within the restrictions of the ABAP Cloud language version).
If there is a better way to model this in the repository / branch structure or if this makes no sense, please let me know.
That's understandable, thank you for the quick response. The way it is currently set up, I unfortunately don't really see the possibility to provide meaningful contributions from my SAP_BASIS 7.58 system. I'm sure other members of the community still depending on 7.58 (or lower) feel in a similar way.
The only "solution" I could think of is to split the repository into two parts: One repository that requires the very latest release, and one repository that offers functionality compatible with lower releases. But I guess at that point one might be better off just using abapOpenChecks which is backwards-compatible down to 7.40 SP 2.
I suggest adding your explanation of the branch handling to the contribution guideline. 😉