Question about best practice for SFDX package versioning with automated builds and deployments:

At present we use git workflow which consists of a master, uat and develop branch. Each branch triggers a build following a successful pull request. When the build runs for the develop branch, it validates the dx project by creating a new scratch org and pushing metadata etc. Following this, it creates a new package version of the metadata and then kicks off a deployment. The deployment installs the new package version into a developer sandbox, along with its dependent packages (using a custom script).

I am now facing a challenge with configuring the build and deployment for the uat branch. The deployment this time will install the package and dependent packages into a shared environment which is used for the UAT of all apps we have. The problem and confusion I have run into is around how I version the package following the successful build of the uat branch. Commits that are pushed into the uat branch are always behind develop , as you may expect. So I really don't want to be creating a new package version for the uat build which is likely to be behind develop.

I have thought of two alternative approaches here

1. When building from the uat  branch, increment the major or minor version of the package (the develop branch would then need modifying to increment the version there too).
2. Rather than creating a new package version for each build of develop, only create a new package version for the uat  build. (I'm less in favour of this as we would then need to deploy the metadata rather than installing a new package version into the dev sandbox)

Does anyone have any ideas as to how I best go about this?