By now you’ve probably heard the news that Chrome OS is moving from a six- to four-week software update cycle. This follows the same change to the Chrome browser, which was previously announced. As a result, Chrome OS 95 will be skipped over and Chromebooks will move from Chrome OS 94 to 96 in the third quarter of this year. It’s a good move but there’s one more thing that should be done: It’s time to reconfigure Chrome OS version numbers to reflect the change.
Here’s what I would propose if anyone at Google is listening. Use month and date Chrome OS version numbers to actually provide meaning to the release cycle.
Think about it. What do you know about Chrome OS 91, which is the current Stable Version for Chromebooks?
Well, you know it arrived at some point after Chrome OS 90 and that’s about it. You don’t know when it released simply by the version. You don’t know based on today’s date if you should have Chrome OS 90 or 91. The same goes for Chrome OS 89, 74, and 61. They’re just arbitrary version names.
However with month and date Chrome OS version numbers, you’d know a wee bit more.
If Chrome OS version 94 starts to roll out in September, for example, wouldn’t Chrome OS version 2109 tell you that? Wouldn’t you know in August not to expect Chrome OS 2109? And if your Chromebook doesn’t have Chrome OS version 2019 by October, you should be looking into why?
Clearly, I’m using a fairly simple naming scheme here.
The first two digits would be the last two digits of the software release year. So the “21” in version 2109 tells you that the software implementation was from 2021. And the last two digits of the version numerically represent the month of that implementation. That’s the “09” in my example of a September, 2021 Chrome OS version number.
It’s a subtle change but a more intuitive versioning system that users get at least some information about. And you could even take things a step further with Google’s Chrome OS Automatic Expiration Dates. If a device is slated to get Chrome OS updates through June of 2027, then it would be supported through version 2706, for example.
That’s not a necessary ask but it could be helpful to enterprises and education organizations that use Chromebooks. It might even be useful for the Chromium developers: All Chrome OS bugs are tied to version numbers today. So to keep track of when their fix or feature add is going public, they have to tie the arbitrary version number to the non-arbitrary release date!
Again, this isn’t a tweak that would bring a massive change to how we use Chromebooks today. It’s not like the addition of a native Linux container for advanced desktop software or Android app support. Those are big changes with large potential value-adds. But it seems like arbitrary Chrome OS version numbers are just that: Arbitrary and semi-meaningless.
Oh and speaking of enterprise and education markets, I’m curious about something.
Support folks in those areas really have to test user software on Chromebooks before rolling out Chrome OS software updates. Does the four-week cycle add any angst in that regard or is it business as usual and you’re looking forward to this? Let me know!
11 Comments
Another great article. Chromeunboxed you need to step up your game, Kevin is outdoing you lately.
Chromeunboxed usually gets its sources from Chromestory.com
Your point is spot-on but the vast majority would better understand your example it if it was 0921, vs. 2109.
True, but that’s not sortable in order for big databases on the developer side. Might be a non issue but that’s why I didn’t go that route. I’m good either way as long as the version number has some meaning. ?
2109 is easier to sort if you need to.
Someone like my wife never even notices that her Chromebook has gotten an update until she’s pleasantly surprised to discover a new feature. When we used Windows, every update was an anxious moment of truth. You knew that it was a necessary thing and a potentially good thing, but it could also result in hours of misery, if not utter catastrophe. I’m so glad that those days are long gone. As long as Google keeps using an imperceptible update process to deliver high-value updates, we really won’t care what they call their updates. We won’t need to care. That’s best.
Yeah that so true Cajun. I bet some people think their Chromebook gets no updates because it’s so seamless. Probably some forum somewhere someone complaining about no updates, lol. Then when that persons comes across the AUE thing their head will explode, 😛
> So the “21” in version 2109 tells you that the software implementation was from 2021
So soon we forget the lessons of Y2K.
Great idea, Kevin. If they really go to a strict 4-week release schedule, there will eventually be months with two releases since there are 4.33 weeks per month. Not a huge deal but there my need to be a YYMM and YYMM-a style naming convention at some point.
I’m not a big fan of this idea, you could quickly break this philosophy as build schedules change. Version numbers are for developers, end users can use names – developers generally like conformity – I personally use https://semver.org/ in my software. Look at Windows – they name their releases in a similar fashion to what you describe e.g. 21H1, but look in the version number and nothing alludes to that. But I can determine whether a build is a fix or new features.
Chrome OS has more detailed build numbers. You can see that today when checking the version on your Chromebook. I’m not suggesting a change to the current process.