Update GSMP Object type

[karevask]

Update object type GSMP

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ karevask
❌ ​ilina.kareva

---

​ilina.kareva seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[Markus1812]

Hi, thanks for the update on the AFF. In the PR, you have commits of two different mail addresses. Your personal gmail and your SAP address. That's why the cla-assistant is detecting two users. I think you can fix this by adding your SAP mail address to your GitHub account. (This way, you can also join the SAP organization if you want). After adding the mail, you should be able to let the cla-assistant recheck this PR and we should be good to go.

Regarding the two changes in the PR:

• Adding async to the instantiation enum is compatible, as there is a default value for the enum.
• Assing extension to the extension mode might be incompatible. Imagine having one system with the enum value and one system without the enum value. If the newer system writes a file with execution_mode = "extension" and the older system reads it, the older system doesn't know this value. And since ty_execution_mode has no default value defined, there is nothing it can fall back to — so it can't deserialize the file properly.

A default value only helps if it already existed in the system before the new enum value was introduced: in that case, the file format implementation substitutes the unknown value with the field's default. But since execution_mode never had a default, adding one now wouldn't help the systems that are already out there — they were built without that fallback rule. So for those systems, adding extension is an incompatible change regardless.

This gives us two options:

1. Accept the incompatibility. If GSMP isn't consumed by abapGit or other tools yet, we could change v1 incompatibly.
2. or bump the format version to v2.

In either case, please also add a $default to ty_execution_mode now, so that any future additions to this enum stay compatible.

Could you let me know whether GSMP is already in use anywhere? That would help us decide which way to go. The async change is fine either way.

Thanks!