💾 Archived View for d.moonfire.us › blog › 2018 › 08 › 13 › publishing-processes captured on 2023-04-26 at 14:04:28. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
Over the last few weeks, I've been tweaking my publishing process. I think I have something pretty stable and started using it for my next novel[1]. After talking about it on social networks, a number of people suggested I write up what I've learned.
1: /tags/flight-of-the-scions/
I appear to be writing a short series of post about the tools I use for publication and writing.
2: /blog/2018/08/21/mfgames-writing-reasons/
3: /blog/2018/08/22/mfgames-writing-init/
4: /blog/2018/08/23/mfgames-writing-content/
5: /blog/2018/08/24/mfgames-writing-docker-and-ci/
6: /blog/2018/08/25/mfgames-writing-formats/
7: /blog/2018/08/26/mfgames-writing-themes/
8: /blog/2018/08/27/mfgames-writing-releases/
Much of how I manage writing projects is to treat them like software. It works well for framing what I have done, need to get done, and what the end goal is. Because of this, I use various features of GitLab[9] pretty heavily: issue tracking for arcs, issues for the publication process, and even more to remind me to order books; milestones to keep me encouraged; continuous integration (CI) to simplify the production of EPUB, MOBI, and PDF versions of the file.
I've also written a number of framework tools such as MfGames Writing[10] to work with CI services for the publication or help me manage stuff (`markdowny`).
10: https://gitlab.com/mfgames-writing/
Recently, I got into a discussion about treating novels as software. Some of the things I do are… strict and not everyone will care for them, but I like to think I'm making my reader's lives easier by the little details that go into my processes.
Somewhere in 2014 or so, I fell in love with semantic versioning[11]. Semantic versioning is a movement to create a common understanding (a grammar) of version numbers that can be understood by anyone to understand the significance of any given release.
A semantic version comes in three parts: major.minor.patch.
I put the version on the legal page so it is present but not obvious unless one is looking for it. There are a number of reasons I do this. The biggest is The Deeds of Paksenarrion by Elizabeth Moon. I have two copies of this omnibus book, mainly because I love it so much. They are two different printings. One of them had a few typos in it that they corrected with a later printing. Having an indicator that there were changes (in this case, a “patch”) would tell me there is something different about these two books.
Lucas, with his reworking of the first three Star Wars movies, would have either new features (the new crowd scenes at the end of The Return of the Jedi) or breaking changes (Greedo shooting first). An example of a patch is redoing the unintended transparency of the X-Wing dash during the fight scenes or reworking the undercarriage of the hover car in the desert (Vaseline verses CGI).
I want to know those changes so when I look at a copy and notice that only the last number changed, it just means there were some typo fixes. If the first, then I start to ask questions, why?
This is also important because some authors will rewrite their books after publication. I also use it when sending books out to alpha and beta readers. Since I get the responses in a semi-random order, it is easier to know that I'm getting feedback from version 0.4.0 instead of 0.5.0. With Git, I can create a branch, manually handle the edits, and then pull them back into the master branch which will then help me consolidate changes between two versions.
Figuring out what goes where (major, minor, or patch) can be a rough.
In Sand and Blood, I'm on version 3.1.0. I switched to version 2.0.0 when I made the book Creative Commons[12]. A license change (from “All Rights Reserved”) felt like a breaking change. I bumped to 3.0.0 when I realized there was a major plot hole about how the clans dealt with the dead (they don't talk about it), so I removed some conversations because I had a better understanding of the world after Sand and Ash.
12: https://creativecommons.org/
There is an important part about version numbers: why. Knowing that someone bought version 1.1.2 of a book and now I'm on 3.1.0 would beg the question: what major changes have happened.
That is where the change log[13] comes in. I'm still working on the format, but I try to document every version of the book, from major to minor to patch. That way, someone can look at the versions and decide for themselves if they want a copy (or to ask for a replacement, which I've done also).
13: https://fedran.com/sand-and-blood/changelog/
Of course, the problem with change logs is that they require some effort to maintain. Over the last year, I stumbled on the concept of a semantic-release[14]. A semantic release is an extension of the version but it automates much of the processes that are involved with figuring out what type of number has to be bumped in the version and creating the appropriate log entries.
14: https://semantic-release.gitbook.io/semantic-release/
One of the goals is to be unromantic[15] about version numbers. I'll admit, I've been romantic about the versions up to this point, but there is something about the systems approach to versions that takes the human factor out and reduces the amount of work.
15: http://sentimentalversioning.org/
Basically, semantic-release[16] is a workflow for NPM packages (and novels in my case) that automates the calculations of verison numbers and also updates the change. It has plugins for publishing that I could use to update my website with the latest versions whenever I make a minor change.
16: https://github.com/semantic-release/semantic-release
It also means that the versions are much smaller. Instead of having 5-10 items in a release, there is probably just one change between versions.
Since I work with Git, there is one component that needs to be done to make semantic-release: conventions. In specific, I use conventional commits[17] which is a standards to identify if something is a minor (a “feature”) or a patch (“fix”). These are done by a convention of the commit messages:
17: https://conventionalcommits.org/
The semantic-release package parses the commit messages (in specific, the Angular[18] conventions) and figures out if it should be releases (any “BREAKING CHANGES”, "feat:", or “fix:” that it sees). Other commits don't bump up the version but still give me the ability to make changes.
18: https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines
I like the structure of using conventional commits and having it automatically feed into new version numbers and creating the change log. Later, it can be used to automate my website[19] and maybe even publish books on various vendors.
This automation is also important for authors published by the various Typewriter Press[20] imprints. All of them have access to their source files in GitLab. They can make changes without me approving of them. If they follow the same conventions, then it will bump up to the versions for their corrections without me tracking them or asking what changed. In that way, it allows non-technical writers to also participate in this process; all without getting overwhelmed by the technical details while still not requiring them to keep track of changes.
Since the version number is pulled into the legal page, it also means that I can easily manage alpha and beta readers, different rounds of editors, and even coordinate changes after giving out multiple copies at the same time (my alpha and beta readers are concurrent).
Much of these concepts also apply to my tools, so I also switched all of MfGames Writing tools to use semantic-release and automate the deployment. Like writing, it lets me focus on what I want to do (write) and automate the tedious stuff (release management).
Categories:
Tags:
Below are various useful links within this site and to related sites (not all have been converted over to Gemini).