I spent more time fighting git and Github [1] than I did in writing the code to support the JSON Feed [2]. Yeah, the code was straightforward and I had it done rather quickly. Deploying the code was something else entirely.
So I finished the code, and the new templates to generate the feed and my tests were good and life was fine. I then committed my changes to git and that's where the first problem occured—not all the changes were committed! The issue came down to an overbroad directive to git to ignore a certain file—it was a general “ignore all files of the given name” instead of “ignore this one file” that I forgot about. So I tagged the release (version 5.0.0), pushed the changes to Github (for public consumption of the source code) and then went to update the copy of mod_blog [3] on the server. It was there when I discovered the critical missing file (one of the templates for the new JSON Feed).
Sigh.
I had been a bit too hasty in pushing the code out to Github, so now I was stuck with releasing version 5.0.1. Only now something got munged up with my copy of the code on the server since it compiled the program with a version number of 5.0.0-1-gd096362 instead of a version number of 5.0.1.
A bit of background: I use git to tag versions, and in the Makefile I have the following bit of code:
VERSION := $(shell git describe --tag) ... override CFLAGS +=-DPROG_VERSION='"$(VERSION)"'
so I don't have to update the version number in code by hand (the override exists so I can specify different compiler flags and still have the version information propagated to the program; I also handle the case when git isn't available, but that comes in later in my tale of woe). Running git tag showed a tag of 5.0.1, but git describe --tag was only coming up with 5.0.0-1-gd096362.
Wat [4]?
Did I not update things properly? Was it a problem with the version of git on the server? Did I lose the signal? Was it lost in translation? Wat?
Some quick changes, try version 5.0.2. That worked—kind of. Now on the server the version was reporting back version 5.0.1.
Then I discovered another issue. I have code in the Makefile to handle the case when the version number isn't available through git—it's just a check to see if git describe --tag returned anything and if not, use a hard coded version specified in the Makefile. Now, to prevent me from pushing an update to Github with an incorrect version number in the Makefile, I have a script that is supposed to run when I push changes to Github (specifically, when I push changes to a remote host). Only the last change to that script rendered it non-executable, so it wasn't running. The version on Github had the wrong version number specified in the Makefile, and I was still having this weird “one version back” problem on the server.
I was still having problems with version 5.0.3 when I gave up. I wanted a nice, clean, 5.0.0 release, and instead, I was on my way to version 5.0.137 the way things were going. And all because I didn't check in a critical file because of a typo. If only I hadn't pushed the code to Github so quickly. If only there were a way to remove the tagged versions from Github, but there didn't seem to be an obvious way to me.
As I eventually found out, there was a way—from the command line on my development machine, I just had to run this blindingly obvious sequence of commands:
GenericUnixPrompt> git tag -d 12345 GenericUnixPrompt> git push origin :refs/tags/12345
Obvious.
I'm surprised I didn't realize that sooner.
So I removed the tags for versions 5.0.3, 5.0.2, 5.0.1, and 5.0.0, made sure I had all the files and whatnot, and re-released version 5.0.0.
Good Lord!
So now all is right with the world, and I have a new JSON Feed [5] file.
[3] https://github.com/spc476/mod_blog
[4] https://www.urbandictionary.com/define.php?term=wat