fix: region visibility modifier to be used by wrappers

[Shahroz16]

Complete each step to get your pull request merged in. Learn more about the workflow this project uses.

• Assign members of your team to review the pull request.
• Wait for pull request status checks to complete. If there are problems, fix them until you see that all status checks are passing.
• Wait until the pull request has been reviewed and approved by a teammate
• After pull request is approved, and you determine it's ready add the label "Ready to merge" to the pull request. A bot will squash and merge the pull request for you after the label is added.

[ami-oss-ci]

Pull request title looks good 👍!

If this pull request gets merged, it will cause a new release of the software. Example: If this project's latest release version is 1.0.0. If this pull request gets merged in, the next release of this project will be 1.0.1. This pull request is not a breaking change.

All merged pull requests will eventually get deployed. But some types of pull requests will trigger a deployment (such as features and bug fixes) while some pull requests will wait to get deployed until a later time.

This project uses a special format for pull requests titles. Expand this section to learn more (expand by clicking the ᐅ symbol on the left side of this sentence)...

This project uses a special format for pull requests titles. Don't worry, it's easy!

This pull request title should be in this format:

<type>: short description of change being made

If your pull request introduces breaking changes to the code, use this format:

<type>!: short description of breaking change

where <type> is one of the following:

• feat: - A feature is being added or modified by this pull request. Use this if you made any changes to any of the features of the project.

• fix: - A bug is being fixed by this pull request. Use this if you made any fixes to bugs in the project.

• docs: - This pull request is making documentation changes, only.

• refactor: - A change was made that doesn't fix a bug or add a feature.

• test: - Adds missing tests or fixes broken tests.

• style: - Changes that do not effect the code (whitespace, linting, formatting, semi-colons, etc)

• perf: - Changes improve performance of the code.

• build: - Changes to the build system (maven, npm, gulp, etc)

• ci: - Changes to the CI build system (Travis, GitHub Actions, Circle, etc)

• chore: - Other changes to project that don't modify source code or test files.

• revert: - Reverts a previous commit that was made.

Examples:

feat: edit profile photo
refactor!: remove deprecated v1 endpoints
build: update npm dependencies
style: run formatter 

Need more examples? Want to learn more about this format? Check out the official docs.

Note: If your pull request does multiple things such as adding a feature and makes changes to the CI server and fixes some bugs then you might want to consider splitting this pull request up into multiple smaller pull requests.

[codecov]

Codecov Report

Merging #260 (58da511) into develop (3cd9cc9) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop     #260   +/-   ##
========================================
  Coverage    56.11%   56.11%           
========================================
  Files          103      103           
  Lines         1153     1153           
========================================
  Hits           647      647           
  Misses         506      506           

Impacted Files	Coverage Δ
Sources/Common/Type/Region.swift	100.00% <ø> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[github-actions]

🎉 This PR is included in version 2.1.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀