Git npm version management during the development flow

Question

Here's my project development process:

• feature/feature1
• feature/feature2
• feature/etc..
• master
• production

I develop my features on the features branches, when I have finished with a branch, I merge it on master and delete it via github ui. CircleCI detect the merge and deploy the master on a staging server. Later I merge manually the master branch onto the production one, and CircleCI deploy to my productions server.

I would like my package.json version to bump each time I merge a feature branch to the master branch (via github UI). But I have no idea if

1. Github allow to do so (if yes please can you explain to me?)
2. It's a good process

I'm aware I could do it via npm version command when I merge master onto production, but I do need the version to be updated on the master automatically when I merge a branch into it.

Don't hesitate to criticize my way to proceed and tell me yours. :)

Thank you

Answer 1

1. I don't think Github offers any such feature. But there are some grunt modules that do this during build time. You could probably script this or have a make file that does this for you as well.

2. I don't think this is good way of versioning. After you are done with a feature, you have to decide if the changes you have made are minor or major. Some times you might commit breaking changes. Just incrementing the version number form 1.0.1 to 1.0.2 or say 1.1.0 to 1.1.1 (every time) will not convey the magnitude of these changes. Best Practice: Software Versioning The best practices for versioning are already covered here.

We manage versioning manually where I work. Before each release we create a tag (v1.0.3, v1.1.4..etc) and then create a release on Github. In the description of the release we put all new commits. Going through the commit message gives us a good idea of the changes that were made. If the changes only involve bug fixes and minor feature additions we will increment the minor number ie. 1.2.1 to 1.2.2. If a major new feature is added, we increment the major version number ie. 1.2.2 to 1.3.0. When we add many breaking changes we go from 1.3.0 to 2.0.0. Sometimes we are loose with versioning. Our API is not public and the only reason we use versioning is for deploying and for rolling back. If you are expecting to make you work open source and or expecting to make your work available through some kind of package manager, like say npm, you should follow semver versioning strictly.