Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Let's say Alice has a Git repository, and the version is kept track of inside the repository (e.g. package.json for npm).
Bob sends a pull request to Alice which increments the version number from 0.1.0 to 0.1.1.
Carol also sends a pull request to Alice (independently from Bob's request) which increments the version number to 0.1.1 as well.
How can Alice deal with this situation?
If Alice is the maintainer of the project, then Alice and Alice alone should be the one that increments the version. Increasing the version number means a release, and Alice is the one to decide when to release - not Bob and Carol.
Whatever code Bob and Carol contribute, you can be 99.99% certain it'll still work even if they don't increment the version number. The remaining 0.01% is because one can always query for the version number and crash the program if it's below the new value. This can be neglected though - Alice should reject any pull request that does that...
Alice should handle this situation by rejecting the pull requests which also change the version number (both of them). Collaborators who are not the maintainer should not be changing the version number - that is the job of the project maintainer.
The accepted answer suggests that only the repo maintainer should increment the version number. This is the usually how things work in projects with a single maintainer, or in larger projects where there might be a number of maintainers but a single designated release manager.
As a counterpoint though, it's not uncommon that versioned internal libraries might not have a single owner or maintainer. Often in a case like this multiple parties could be bumping the version with only loose coordination. This situation isn't bad, assuming all contributors understand the release process and are trusted to execute it. In this situation, it's the responsibility of the party that merges second to correct the version number. So in the example, if Bob merges first then Carol is responsible for updating her request to bump the version to 0.1.2, and vice versa if Carol merges first Bob will produce 0.1.2.
An approach like this won't scale indefinitely, but there's nothing inherent in git or typical versioning strategies that requires there be a single party that is solely responsible for producing new versions of a software package.
In particular git itself is a distributed VCS, and if a version number is stored in a tracked file then that file is managed the same way as any other file. Concurrent edits to the version file can produce conflicts and will have to be resolved by human intervention, the same way as any other tracked file. The only additional consideration is that version changes typically come along with a publishing process and re-publishing the same version is either a bad idea or not permitted depending on the ecosystem, so some additional care has to be taken in the publishing process, but ultimately there is a correct answer to "what is the correct value for the version file?" that depends on the history of the project, when that history changes (e.g. a merge or rebase occurs) that answer may change but there doesn't need to be a single arbiter of releases to produce a correct answer.
The best way to deal with this automatically would be flagging a PR to be a major/minor/patch version bump and then having a CI/CD job that would bump the version according to the flag.
This means that neither Bob nor Carol would actually change the version in the PR and the resulting version would depend on the order in which they'd merge their PRs.
I actually use this strategy in my company and I am quite happy with it.
