I don't undwerstand Rails gem development workflow with git tagging. When developing a Rails gem there is a file VERSION that looks something like this:
module YourApp
VERSION = '1.0-beta-1.14'
end
The version in that file seems to matter because if you have a mismatch in the Gemfile of a Rails app that uses said gem, it vomits concern. Say you update the gem and don't bump the version, well you won't get the changes next bundle update. If you do bump the version and also update your Gemfile with that version you will get the update but if you want to go back a version, bundle can't help at all. As far as I can tell it won't magically roll back to the last commit that has the target version.
So then, OK, that what git tags are for, but this is also weird in the sense that you still have to babysit the VERSION file of the gem repository. Why do I need them both? Can someone explain this? For example, is there a simple workflow where I don't have to babysit the VERSION file and only need to worry about git tagging? How do I update the gem repository version as I develop, like if I want a tag or a VERSION to reference an update set of file that is continuously refined, does that defeat the whole point of tagging or VERSION changing? It really doesn't make sense to me. Like I can go through the motions to get the result I want but I am simply not understanding how both mechanism work together in an optimal workflow.
Any thoughts/help appreciated
This is apparently a known headache solved with the gem-release gem. It seems trivial at first, but in my case, this made my workflow much better. If you frequently version as I do and value rolling back; this is quite helpful, at least for me.