TLDR: Instead of naming the next version of AppGini 6.0, it would be 22.0 as we’ll start using a new version numbering scheme that encourages rapid release cycles. More details below.
The previous scheme for versioning AppGini releases went something like this in most previous releases:
{super major release}.{major release}{minor release}
Let’s take AppGini 5.84 as an example: 5, the first digit, is a super major release number. So, moving from 5.xx to 6.00 means (as expected by me as AppGini developer and, my guess, also by most users) adding an enormous, paradigm-shifting change. 8 is a major release number, meaning that to move from 5.8x to 5.90, there must be at least 3 or 4 considerable new features. And finally, 4, the last digit, is a minor release number; version 5.85 is expected to have some bug fixes and minor enhancements over 5.84.
To be clear, the above is not some kind of an “officially declared policy” placed somewhere on our website. However, it’s been the way we used to number releases in most cases over the past 20 years.
This scheme has always imposed artificial barriers on the frequency of releases and which features get included into each one. It’s led to delays that we could have easily prevented had this scheme not been in place.
For example, take the very frequent case of making bug fixes and minor enhancements that we can’t call “new features”. This should be a minor release, right? But how many minor releases can we publish before we hit a wall? The above versioning scheme is forcing an artificial limit to how many minor releases we can make after a major release. Take the major release number 5.80: there can be only nine minor releases, 5.81 to 5.89, before a major release has to be published.
And because there are only nine chances to make minor fixes before having to release a major version, we had to delay minor releases in order to include as many fixes into each as possible. This has continually led to a delay of new features as we tended to “stash” them away till the next major release.
Even worse, combining a big list of fixes, enhancements and features into a single release to work around the version numbering limitations, often means a big number of issues could also be introduced. When the number of changes is small in a release, bugs are manageable and easier to discover, trace and fix. But with a large number of changes, this becomes a nightmare.
At the time of writing this post, the current version is 5.98. Now I feel really stuck, and have been so for a few months: We have a few fixes to make, but we have only one single minor release remaining: 5.99. After that, we have to move to … drum roll please … AppGini 6.0.
AppGini 6.0 is not a normal major release .. The expectation is that it should be a “world-changing” one, where there must be at least 3 or 4 huge new super features. Oh, but … but we have a couple of small new features ready to release? No, that has to wait till 2 or 3 huge features are also added. But what if we have some fixes to make after 5.99? Sorry, we’re out of luck, no can do! Maybe wait until 6.01 :/
See where this is going? We’ve kind of hit a wall here. This is not going to work, and AppGini 6.0 might have to wait for 4 or 5 months or even more. And this is unfair to users and to AppGini itself.
This is why we have to introduce a new version numbering scheme that removes those artificially imposed restrictions. One where we can make any number of changes of any kind (fixes, enhancements, minor or major new features), and once they’re ready, they get released.
Turns out this is not an uncommon problem with software … Firefox had it, and so did Google Chrome and the move to this versioning scheme is generally associated with rapid release cycles of software.
So, this is the path we figured is the better way for AppGini to follow. We want users to be able to enjoy new features as soon as possible, and get issues fixed quickly, without having to wait for some unnatural versioning scheme. As a bonus, any potential bugs in new releases get fixed way quicker.
The new versioning scheme we’re going to follow begins with the year number (last two digits) follow by a dot followed by 2 digits. Thus, in the year 2022, version numbers would be 22.0, 22.1, 22.11, 22.12, and so on up to 22.99. In the following year, 2023, numbers would be 23.0, 23.1 and so on. This gives us the freedom to release up to 91 versions per year. We probably won’t make that many releases in each year, but a new version every couple of weeks would become possible.
We anticipate that this change will lead our valuable users to see more frequent new features, quicker bug fixes, and less surprising changes.