Scott Marlowe, fantasy author

Scott Marlowe

Author of the Alchemancer and Assassin Without a Name fantasy series

eBook Versioning

In the world of software, version numbers are used so people can distinguish between different product versions or builds. The following is one way in which version numbers are broken down:

(Major version).(Minor version).(Revision number).(Build number)

Let's look at each of these.

  1. Major version: The major version can be thought of as the product version. Office 11, for example, where '11' is the major version.
  2. Minor version: The minor version often indicates a point release containing enhancements, bug fixes, and generally significant improvements just short of the product warranting a new major version.
  3. Revision number: If major and minor versions of a product are identical but have different revision numbers, then those assemblies (a DLL, for example) are meant to be interchangeable. A new revision might indicate, for example, that a security hole was plugged. Functionally, though, the two assemblies are identical.
  4. Build number: The build number is associated with a compile of the program or product in question. Depending on a team's build schedule, a new build number may be generated at the end of each day or less frequently.

That may seem overly complicated but it's really pretty commonplace in software product development.

So how about books? Do books have version numbers?

Why yes they do.

The version number of a book is called an 'edition'. One possible way to break an edition number down is to express it as, for example, 15/30, which means the 15th print  having a volume of 30 units. Otherwise you may just see a simple sequential numbering system. Not very complicated.

When I first released my eBooks I was following a versioning scheme more inline with software development, except without the build number part. So, something like 1.0.11, for example. The major version never really got updated but I had a number of point releases to correct typos and such. The minor version never got updated at all. So I dropped it. I also came to realize over time that having a major version didn't make much sense either, cause when was I ever going to release any major changes? Hopefully never. The types of releases I make are really only point releases resulting in a revision number increment.

So what versioning scheme am I using for my eBooks now?

I'm using a simple sequential numbering scheme. I put the version right on the copyright page:

image

The version serves the obvious purpose of tracking changes and letting readers know there have been changes, corrections, etc., but it also lets me know which version I have uploaded to the various retailers who sell my books. It's an easy way to verify that everything went smoothly with the upload just by taking a quick look at the preview via the retailer's site the same way anyone else would.

I need to get better about tracking the actual changes that go along with each version, but that's a task (and maybe a post) for another day.

Conclusion

eBooks are digital and as such share similarities with other digital entities such as software applications. Even traditional, paper books have versions, so why not eBooks as well? It makes it possible to track changes if that's something an author wants to do and lets readers know that the book isn't static and that mistakes (we all make mistakes) are being actively corrected. That last point makes me wonder if I shouldn't add a "Last Revised" or "Last Updated" date in there somewhere. Hmm…



Comments (1) -

  • Daniel R. Marvello

    12/18/2012 7:33:35 AM | Reply

    I like your idea of putting a version number on the ebook release, but I think I'd make it less prominent to avoid confusing potential readers who might try to read something into it. I'll probably stuff mine down with the ISBN list.

    I've gone to a simplified versioning system for software development too. I use (release).(revision). The first release that goes to QA is 1.0. While in the QA cycle, if the software needs changes before it goes to production, it gets a new revision number (e.g. 1.1, 1.2). As soon as that release goes to production and I start the development cycle for a new release, I increment the release number (e.g. 2.0). This approach would probably not be sufficient in a large team environment with automated nightly builds, but for my own projects and my contract jobs it works great.

Loading