How do you handle bump versions on deployments? Before building the release/upgrade I do a commit containing only the version bump. But I’m tired of doing this and I feel like there must be a better way. So what do you guys/girls do? I’ve heard mentions of putting it into a text file on the build server - is that the best way?
What about just automating the tasks of bumping the version locally. You could’ve a mix task or a makefile just do the stuff you normally do.
That is a good suggestion. But I would like to not have the version bump commits in my commit history at all. Is that stupid? It would also make building the releases on CI easier 
The releases in edeliver contains the commit hash so I can identify what commit was deployed that way.
I’m actual all for extra commits for version bumps. If you bump the version together with other changes it feels like those changes made the version be bumped, but that’s hardly ever the case.
1 Like
I agree that if the version bump should be a part of the commit history at all it should be it’s own. Right now that is the only thing I commit directly to the master branch. Everthing else is done via pull requests. But I am just not sure I think it is essential to the project what version it is in the mix file. Maybe it is fine
It does keep things explicit which I guess is a good thing
I tag the commit (a real commit, with the actual last changes) with a particular format (v1.2.3), then use git commands within mix.exs to extract the latest tag, set up the version attribute for Elixir to use, and also write it into a file where it will get picked up by all my build/deploy scripts (for Docker, for Kubernetes) in the rest of the pipeline. This way the app can return a version header, and the automation guarantees that it is consistent with the git commit deployed, and the version tag in the Docker registry, and the version in the K8s deploy.
2 Likes
That is a neat solution indeed.
And I forgot to mention how the git tags command works. If you’re on a commit that has a tag, it returns just the tag. If you’re not, it returns the last preceding tag, “-”, # of commits on this branch since that tag, “-g”, and the short hash. I rather like that intended release builds in the dev registry are tagged as 1.2.3 while subsequent dev work will be like 1.2.3-7-gxxxxxxx
2 Likes
Yeah @sribe’s method is what I do in Python, Java, and C++ as well, it works very well. I just take the last-most tagged version in the current git branch like v1.2.5 and append the current count of the git commits since along with a dot and the current hash, and strip the leading v like 1.2.5-14+31ad7e2 or whatever, I forget the exact syntax though it follows semver and I keep copying my script around. ^.^;
git describe --first-parent
1 Like
