Who is responsible for bumping version number in commercial software development?
How to setup policies for that?
1) for small team
2) for medium team
It is important not to forget to change the version number that self-describes that output file.
Such as AssemblyInfo.cs / resource.rc / AndroidManifest.xml
2
Version numbers are a product management / release management responsibility. It is not a developer choice. You should setup your build environment to easily allow version numbers to change. I would go as far as saying the whole build environment and build system can be setup to allow the PM or RM to set it to whatever they want. And the developer doesn’t care.
If the version number is visible by the user, it’s a public relation decision. I’ve seen the major number be modified as there was a user change deemed important by the marketing department but with little impact on the code, as well as big code reorganization but with few user visible change resulting in the smallest possible change in the numbering in order not to hinder upgrades.
Not that is true for commercial software as well as open source one. There is often no marketing department for later, but the rationale for the decision will be public relationship quite rapidly after the software has success. Or it will be used as way to get renewed attention or to delay that attention until one is ready.
IMHO, the best versioning scheme is semantic versioning, and in this scheme, no role is specified, rather, rules are specified.
In other words, if Office introduces new features, and some of the oldest functionalities are gone, then the major version should be added another unit. Now who does that? Usually developers. Because they are the people to whom version matters most.
1