How do I manage version numbers with Github Flow?

Admin 1
Viewed 1324

I have a Discord bot that I recently decided to make open-source (here). It is currently using the Git Flow branching model, and I want to change to Github Flow (removing the develop branch and merging new features directly into master). The actual transfer only requires merging develop into master and deleting it.

However, the project currently uses semantic versioning, and the version number is displayed in the Discord bot's status to help users know when it has updated. What do most open-source applications do about version numbers? Create a commit to bump the version number right before merging a pull request and deploy the new feature straight away, or make tags when they are ready to release?

Does it make more sense to just remove the version numbering entirely?

github git
1 Answers

The approach that many projects, including Git, take is to generate the version number using git describe when the project is built from a Git repository, and to provide a fixed version number, usually somewhere in the source code, that's bumped as part of the release (or included as an extra file) for tarball or other package releases.

If these tarball and package releases are built using a CI system, you can actually automate this process by generating it from the tag and never have to bump the version number yourself. That may be more work than you want, though.

There's no need to bump the version on every pull request, and that usually ends up being a bunch of work that can cause lots of conflicts. It's usually easier to perform regular releases when it seems like enough bug fixes or features warrant a new release. If you use the git describe method, then people running non-release versions will still have a distinct version string from released versions while allowing you to retain semantic versioning.

user_87054320
Related