proper order of tags and version bumps

I have a library on github which uses rebar, but it has never been tagged via git. As of this writing, the app.src file indicates it is version 0.1 (this has never been changed).

I'd like to make some commits which will change some of the function definitions. I need to use tags and application versions so this doesn't negatively impact users, but I'm unclear on the order I'm supposed to tag, bump, etc.

What steps do I take now and in the future in order to ensure that users can code to the version of their choice?

Solution

I use the following scheme in my repositories:

X.Y.Z where X is major, Y is minor and Z is patch releases (taking some ideas from Semantinc Versioning)
The order I change .app.src files and tags is as following:
1. Make the change, bump version number in the .app.src file and commit it with a nice commit message.
2. Tag that commit using the same version number as in the .app.src file. I enter a tag message of the following form:
```
Version X.Y.Z

- New Feature 1
- New Feature 1
- Fix this and that
```
  The tag is then GPG signed with my signature (using the -s flag)
3. Push the commit with git push && git push --tags to upload both the commit and the tag to the server.

I don't use semantic versioning's "vX.Y.Z" scheme as tags because I think it's superflous and doesn't look very good.

Once you have proper tagging and versioning (of your choice) your users should be able to rely on using the Git tags as is.

You can see the results here: https://github.com/eproxus/meck (you need to download the code to see the tag messages and verify the GPG signature).