Hi team,
Sorry for the complexity here!!! I totally get that not everyone loves the naming scheme. And yeah, you can say - marketing is stupid, Iâll give you that. Part of the reason for that is because marketing deals with humans and weâre all strange animals, you knowâŚ
We need the version numbers to communicate new versions to press and people who donât know Nextcloud. Thatâs important - not directly for all of you, but to get in front of people who donât yet use Nextcloud helps, indirectly, everyone 
We have a bit of the same challenge as the Linux kernel: when 6.17 comes out, nobody blinks. When it moves to 7.0, thereâs quite some coverage. In reality, both are equally big releases, as Linusâ rule famously is: âwhen I canât count it on fingers and toes anymore, I go up a major number.â
At Nextcloud, weâre at 32. Going to 33 sounds - like a small step. Version 1.0 to 2.0 sounds MUCH bigger. Of course, the amount of changes going in 33 are far bigger than what we did, per release, back in 2016âŚ
So, we came up with Hub, reset numbering - but thatâs also well over 10. Year will scale better, as bb77 pointed out. yup yup. Then how do we differentiate the 3 releases in the year? Ideally it is ordered - random-ish names like Cumulus doesnât do that. 26.1 and 26.2 is ordered, but sounds like minor releases. We thought - seasons have an order, letâs do that.
Given Hub 26 Spring, Summer and Autumn, you know whatâs newer and what is older. Unfortunately Winter is indeed a confusing factor - can be beginning or end in the northern half of our planet. Summer has the same in the south. Mja. Nothingâs perfect I guess
for now we do this.
Of course, you can keep using 33-34 and so on if you prefer, we will have these numbers in the product and on our changelog and download page etcâŚ