The Toucan product is made of multiple sub-systems, two of which being the most of it: a web client (Tucana) and application server (Laputa, named after the flying island depicted in Myiazaky’s animated film). These two components are reaching their 100th version this week! Let’s take a short trip down the 8-years memory lane of Toucan software. 💯
Why talk about “special” version numbers?
The version 100 is not always just about crossing a symbolic threshold. In some cases, changing a version number from two to three digits can cause unexpected problems.
That will be the case of Chrome and Firefox hitting the hundreds (in March and May): as many website rely on parsing two digits in the User-Agent string, they may believe these browsers are back to version 10 or 00! (More on broken User-Agent string detection) Fortunately, these browsers have mitigations in place, and have warned developers.
It reminds me also of the leap of version that Windows took from 8 to 10. It was speculated to be driven by fear that many legacy programs would mistake Windows 9 with Windows 95 or 98 (by some code like os.startsWith('Windows 9')). This was never confirmed by Microsoft to my knowledge.
For us at Toucan, there is little risk of breaking anything 😆 . Just a harmless celebration 🎉
A bit of analysis on release data for fun
Since most of our release process is automated, we release a lot at Toucan.
For fun, I’ve extracted from GitHub API the list of releases on our front-end repository, alias Tucana.
Since 2014, we’ve released this repo 1778 times.
Our version numbers follow the usual MAJOR.MINOR.PATCH format.
Our release process has evolved much across the years, and that can be seen by looking at the release time of major releases.
At first, we did increase the major version only when doing breaking changes between our front-end and our back-end, but that was erratic and somewhat difficult to determine at the beginning of the product life. Also, as we were a really small team with not many on-premise customers, we did not commit to updating these as regularly as they should.
We then decided to increase this version on each iteration of our release process, which could happen on weekly or on a monthly basis.
Since January 2021, we release one major version every month. That simplifies greatly all the communication around new features between us and our users, and create more predictability in when the features are gonna be released. We can see how the line has became straight since!
Exploring the minor versions gives an idea on why we made some of these changes.
In 2016, when we were following semantic versioning rules, our minor versions skyrocketed, going up to 20! As it’s easier for non-technical to speak about version 20 that speaking about version 4.20, we’ve decided to move towards increasing the major more often. This decision makes sense for a product. It’s of course different when developing a library: semantic versioning is really important to update them with confidence (to some extent).
Since January 2021, we don’t publish minor versions at all.
Another funny (or not so funny maybe!) study is to look at the quantity of patches for each version (major.minor):
Mention to the release 81, with a solid 31 patches!
Note that, as the release process is automated, the best interest of our users if for us to release as soon as a bug fix is merged, so it can be deployed as soon as possible. However, the trigger to create a patch release is still manual, so we can batch multiple fixed together in the same patch release if they are gonna be merged in a short time-frame. So we cannot deduce the number of bug-fixes directly from the number of patches 🤷♂️
Last note on automation: by looking at the author of the number of releases authored by individuals (manual) versus ones made by our service account, we can clearly see that automation drove up the number of releases per year. Up to a point when decided that less releases was easier to follow for our customers!
Not just numbers!
For a time, we used to name our releases, sometimes using the excellent Code Name Generator, sometimes with tasty recipes 😋 (food is always a loved topic at Toucan) or references to very appreciated colleagues 🥇 .
In these names, the color Purple is the most popular. It’s my favorite color, but that’s totally unrelated, right? 👼 💜
We had the best vegan meals: Zesty Quinoa Salad, Cilantro Edamame Hummus,Crispy Seasoned Cauliflower,Peanut Butter Acai Bowl, Zucchini Matcha Oatmeal, Green Smoothie Popsicles, and the excellent Banana Cream Pie (did you doubt that was a tasty recipe?).
some unexpected animals: Drunk Goose Island,Joly Jumanji Goosebumps, Black Uranium Shark,Zen Hoppy Wolf,
some brewing ideas: Equity For Punks, Trick Brew Ale, James Bruwn Stout,
and some…miscellaneous: Corona Profane Season (you can imagine when this happened!), Bi Ba Boo (noone remember if that ever meant something) and Salty Kiss Party (seems like a good one!).
Anyway, giving these funny names was a good motivation to write nice releases notes for each of these releases, with a sparkle of fun 😉
It’s, of course, just the beginning of the story. We will have many more releases in the future, filled with wonderful features. May we reach the v1000 one day!