[newtork]

(low priority)

We had a customer issue in v4, where the complaint was default new ObjectMapper() was serializing a customFieldNames : [] for every OpenAPI entity. For them it was unexpected and faulty behavior.

While the cause is based on improper SAP Cloud SDK class usage, still we could have a little house-keeping here.

Needless to say, I have no personal stakes here. If you decline the change; fine for me :)

[Johannes-Schneider]

Changes LGTM - they are also simple enough to "just ship it" IMO.
Do we need a release note?

---

How are we dealing with backporting changes? Since this change is so simple (and we do have a customer issue), backporting shouldn't be a lot of effort. But not sure whether we already had a team decision for that.

[newtork]

How are we dealing with backporting changes?

Of course we can backport, but since this is not a "real" bug, I felt it fits better the next generation SDK ;)
Not aligned yet with PO.

Not sure whether we already had a team decision for that.

There was no team communication on this yet.

[jjtang1985]

How are we dealing with backporting changes?

I dont have strong opinion here.
In general, back porting is only needed for urgent bugs/features, or very small PRs.

Here some bullet points of this issue:

1. This is not a bug, but due to unexpected use cases. I would hope that they use the documented features of the SDK.
2. The runtime behaviour changes are triggered by 1 (maybe together with other dependency updates), instead of SDK source code changes.
3. Workaround is provided, so they can continue with the current unexpected use cases. I've just asked for their feedback.
4. As the consumer used Business Logging service, instead of the generator, I guess this change will not help them directly, unless we also update the Business Logging clients.

I feel maybe we can wait for their response first.
If the workaround does not help, then we take some actions?

Do we need a release note?

As an improvement, I guess we need some release notes.

[Johannes-Schneider]

I dont have strong opinion here.

Neither do I.
I just thought it might fit quite nicely as we are planning to do a v4 release anyways.

As the consumer used Business Logging service, instead of the generator, I guess this change will not help them directly, unless we also update the Business Logging clients.

That's a very good point.

I feel maybe we can wait for their response first.
If the workaround does not help, then we take some actions?

Sounds like a plan. 👍

[newtork]

This is why I phrased the PR as house-keeping, not as bug fix :)

[Johannes-Schneider]

@newtork would you mind adding a tiny release note so that this PR is ready to be merged?

[Johannes-Schneider]

LGTM