How to manage updates after a release?

Question

I wonder how should we manage the commits we make AFTER a version is released, according to SEMVER. For example, I just released 1.0.1, now I have 2 choices:

• Immediately change version to 1.0.2 and start working on this version. Once the work is finished, I'll just tag the last commit to be officially the version 1.0.2 (this seems to be the SEMVER-way of doing it).

• Continue working on 1.0.1 and then when I finished, I make a commit to change the version to 1.0.2 and tag this last commit as the official version 1.0.2.

Actually, SEMVER tells that

Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version.

But the second way seems more logical to me, as when a version is incremented, the software should already have all the functionnalities of this particular version. So what should I do?

Answer 1

SemVer doesn't really say anything about how you should structure your repository and your workflow around it in order to achieve it. Because it is really just is a standard for naming versions of software. So there really isn't a right or a wrong way to generate those versions.

To add two more approaches to what @Gladen has mentioned.

• One approach I've used for small-to-medium OSS projects, especially library ones, is to have a single master branch to which all work is committed. Sometimes there will be feature branches, for bigger work. When enough work has accumulated, I'd use a git tag to mark a certain commit on master as a new release point. The tag would look something like v0.3.7 or v1.2.4. The CI system would be configured so that for commits tagged like this it would also do a "deploy" step. This can mean just packaging a library and pushing it to a repository, but I've also done actual application releases in this fashion. Though I prefer to keep the release process separate nowadays.
• Another approach I've used is to have master as a sort of work log. Actual work is done on a feature branch derived from master and periodically re-sync-ed with it. After the work is done and passes code reviews etc. the branch is merged into master at which point you can also force a semver increment of the patch/minor/major version - depending on the work done on the feature branch. The merge generates a single new commit on master, with version info in it, which then triggers a package release as well.

Answer 2

We use git with gitflow, and our workflow is normally like this. We have 2 permanent branches, master and develop. Master contains the active production version.

Say we have a situation like in your example and master currently contains 1.0.1, and we find a critical production issue. What we do then is create a new branch from master called hotfix/fix-1.0.2. In our case we immediately bump the version and then start working on that branch to fix the issue.

Once we are done, we merge the branch back to master and deploy the new version, and we merge the hotfix branch to develop as well so all changes are in the current development version as well.