Designing Pillars of State - Versioning
I am an experienced software engineer who specialises in geospatial software and data heavy applications. I also spend my free time doing game dev and working on procedural content generation.
When people want to talk about games or applications, versioning is not near the top of their minds. It's not a dirty word, but most people consider it either trivial or boring. The truth of the matter is, versioning is important and it helps shape the way we view products.
There are a variety of common versioning systems and choosing one indicates a lot about the way you plan on managing and releasing your product:
3-digit semantic (major.minor.patch -> 0.1.0): Anything above 1.0.0 denotes release, and anything below denotes pre-release. Early access for Steam requires your project to be released within 1 year, therefore you need to be 1.0.0 by that time.
4-digit semantic (major.minor.patch.build -> 0.1.0.42): Similar to the 3-digit semantic, but you also include the build number. The build number could be anything, but I have seen this be the number of days since development started, each version compilation, or some other internal identifier.
Calendric (YY.MM/YYYY.minor.patch -> 23.01/2023.1.0): This is great for projects in constant development or SaaS projects. It lets your client know how recently an update was put out but also has the downside of highlighting dead projects.
Percentage (0.42 -> 42%): This is rare, but famously used by Dwarf Fortress until launching on Steam. This requires you to know your project's scope in full, so you know how far along you are. Zach and Tarn Adams write a story about the world of Dwarf Fortress, identify work items in the story, apply a percentage to the story and when completing the work items adjust the release percentage.
I love the idea of writing stories and generating work items from the text. I think this is a great way of defining scope through narrative, and it is similar to epics/user stories used in agile project management; the dominant project management methodology in the software industry. I don't however think using percentage versioning is a good idea for most people.
Even though versioning is often used to communicate the state of a project with users, it is a great way to help with motivation. It gives developers an easy way to set milestones which can be achieved and celebrated. Motivation is often lost because projects seem unachievable, and it is because developers fail to put in motivational strategies.
For Pillars of State, I plan on combining stories with the 3-digit semantic versioning. 1.0.0 would still be considered a release, however, stories would define the minor version steps (e.g. x.1.x -> x.2.0). This has the added benefit of controlling scope and targeting user suggestions, as users can read the story and suggest elements that might not have been converted into work items already. Scope creep is a major issue in most projects, but can be a killer in complex projects with user interaction.
I imagine anyone who is still reading by this point is a project manager who wishes all developers would value project management more, but the key point to take away is simple.
Empathise with your future self by utilising little methods to help with motivation and success.
In the next blog, I will be writing a story for Pillars of State, reviewing it for work items and looking at project management tools. In the meantime, if you have any comments or suggestions, I would love to hear them.
