I’m not sure what you mean by “bumping the version in source after a release”. If it’s after a release then you released it with the old version? Or do you mean prep the repo for the next version by incrementing it optimistically, in which case it probably depends on your branding model. But I don’t understand the “immediately” part of your question.
Where I work we don’t increment until we know what branch/version we are working on, and determine the semantic version, and then we still use tagging because we tag the version + build id which is computed at build time
My understanding is that initially they have version 1.4.2 and release 1.4.2. Then in the next commit, immediately after release, they bump the version to 1.4.3.alpha0 or something of that nature.
I personally think that's messy because it requires two changes to the version instead of one and there's no way of knowing that the next version will be 1.4.3. If a developer makes a breaking change, will they update the version in the code to 2.0.0.alpha0 or do they fix the version when they release?
I suppose if you have nightly releases then it could make sense but then I think using the date or the commit hash as the version number would make more sense.
Where I work we don’t increment until we know what branch/version we are working on, and determine the semantic version, and then we still use tagging because we tag the version + build id which is computed at build time