Automatically bump foraging_gui version

[alexpiet]

Pull Request instructions:

• Please follow the update protocol
• Answer the questions below in detail. Your responses will be emailed to experimenters.
• If the experimenters must do anything new, provide detailed step by step instructions on the wiki
• If computer maintainers need to manually update anything, provide detailed step by step instructions
• Use markdown syntax in order for your comments to be rendered reliably in the email: "1." instead of "1)", use four spaces for indents.
• If you use the keyword "skip email" in the title, it will skip the email updates
• Merges from "develop" into "production_testing" should use the keyword "production merge" in the title for reliable indexing of updates
• Merges from "production_testing" into "main" should use the keyword "update main"

Describe changes:

• Increments the version of the foraging gui package with every merge to main. This means each week's release will have a unique tag. Right now we have 0.0.0, this will increment to 0.0.1, then 0.0.2 and so on. I propose we manually bump the minor version (eg 0.1.0) when we have updates that requirement manual intervention
• Then in python foraging_gui.__version__ will reflect this version number. This will improve clarity of metadata and issue tracking
• Logs this version in the GUI log, and in session metadata

What issues or discussions does this update address?

• resolves #218

Describe the expected change in behavior from the perspective of the experimenter

• none

Describe any manual update steps for task computers

• none

Was this update tested in 446/447?

[alexpiet]

@hanhou @XX-Yin This is ready for review

[hanhou]

Should we start to add release type to the commit message?

https://github.com/AllenNeuralDynamics/aind-library-template?tab=readme-ov-file#semantic-release

[alexpiet]

@hanhou I'm not sure how to integrate that into the automatic PRs for the weekly merges to main

[hanhou]

You are calling tag.yml in aind-github-actions, which in turn uses mathieudutour/github-tag-action@v6.1 (this line), right?

I guess how it works is that it will analyze the type prefixes of all commit messages inside a PR and determine the highest level of change:

• If there are any commits with BREAKING CHANGE, it triggers a major version bump. (0.0.0 -> 1.0.0)
• If there are any feat commits but no BREAKING CHANGE commits, it triggers a minor version bump. (0.0.0 -> 0.1.0)
• If there are only fix commits and no feat or BREAKING CHANGE commits, it triggers a patch version bump. (0.0.0 -> 0.0.1)
• If we don't use any type prefix, as before, it will always trigger a patch version bump by default. (See "default_bump " here)

So there are two options for us:

Option 1 (what you described): we don't use type prefix in the commit message as before. In this case, weekly PRs always bump the patch version number by default. When we need to tag a manual intervention, we manually bump the minor or major version.

Option 2: We adopt the Angular commit message conventions. In this case, if we want to indicate the requirement of manual intervention, we can add "BREAKING CHANGE:" to the footer of the commit message to bump the major version number. Otherwise, the github action automatically handles patch (fix) and minor (feat) version bumps for us.

I think Option 2 may be a better practice in the long run.

[alexpiet]

@hanhou Thanks for explaining that! Option 2 seems to be great.

[alexpiet]

Do we need to make any changes to this PR? I think we just need to enforce standards on commit messages