Added new CLI option to support better control over managed object names

[pmckeown]

Related to frodo-lib#480 - adds the CLI option --use-realm-prefix-on-managed-objects to support enabling this feature in the Lib.

[pmckeown]

There is no v2 branch - a branch would need to be created from v2.1.0 to allow this to correctly target the correct codebase.

[pmckeown]

Hi, can someone please provide me with an indication if this change is under consideration?

If it is I will add tests for it or modify as needed.

Please don't discount this due to the conflicts. They are present as there is no 2.x branch to target.

Also, I will add this to support v3.x if needed.

[vscheuber]

@pmckeown Nappy New Year! :) And THANK YOU for your PR! We are working through a queue of some large PRs from contributing parties and I am super excited to get to yours. Please bear with us as we catch up. I will leave more comments here with questions or feedback.

We do not follow the practice of release branches to keep our code maintenance to a minimum. Your PRs should always go against main and will be merged into main and become immediately available in the next pre-release.

[pmckeown]

@pmckeown Nappy New Year! :) And THANK YOU for your PR! We are working through a queue of some large PRs from contributing parties and I am super excited to get to yours. Please bear with us as we catch up. I will leave more comments here with questions or feedback.

We do not follow the practice of release branches to keep our code maintenance to a minimum. Your PRs should always go against main and will be merged into main and become immediately available in the next pre-release.

Hi Volker, thanks for the response. I guess that means it needs to be compatible with v3 - though our codebase at the minute is not due to some breaking changes from v2 to v3.

Once we get our codebase up to v3 and the deployments working using that version I will redo this PR as you are essentially saying that no additional fixes/changes to the previous releases will be made right?

[vscheuber]

@pmckeown Yes, you are right. In rare instances we have created a feature branch (1.x) but that was due to the fact that 2.x was basically a re-write and absolutely incompatible but we had a user based sitting on 1.x and so we needed to be able to fix bugs for a while until everybody made the upgrade to 2.x.

The 3.x release really is not that much different from 2.x but it contains breaking export/import format changes in a few places, so we decided to make a major version bump.

If I may ask: What is breaking you in 3.x?

[pmckeown]

There were a few little things that blocked us from upgrading. E.g. there was a bug in the JSON mapping of the journey file structure in the new codebase, or we needed to update our journey config files from $.tree to $.trees. But mainly it was too much work on and not enough time to migrate. I will try and find time to upgrade again and raise this PR again if needed against the main branch. For now we are using a custom build which isn't ideal but allowing us to deliver the project.