Ah, well you could say that the daily builds do add a minor version at the end, but the public releases always just treat the version as though it were a normal number. 2.49 lead to 2.50 not 3, 2.69 lead to 2.70, and recently 2.79 lead to 2.80. They have yet to jump to 3 on any of these releases. If you look at the blender releases archive, some versions were skipped early on, but they have never treated the number before the decimal as a major release in the whole history of the program.
Exactly, because 50 comes after 49, and 80 comes after 79. and after v2.99.0. we will have v2.100.0. Until the development team deems a version to be a major update (v3.0.0), we will continue counting up minor versions.
The Blender development team is using a standardized version numbering scheme. It’s the community that is choosing to ignore it or misinterpret it. It’s as simple as that. That’s all I’m complaining about.
Yes I’m a pedant, but the software industry is full of them because it’s important to care about minor details when developing software. 
I don’t think you get what I was saying. Yes if .99 were the “minor” version, then 2.100 would come after 2.99, however when you look at how the versioning has been done so far, it seems they haven’t designated that point number to be the “minor” version of any release so far.
For example, the version of 2.79 I have is the old experimental version from before 2.80 was stable:
It seems they do add a “minor” version number to the experimental builds, but this number never appears in the “stable” releases that come out. It looks like the foundation uses a scheme where no stable release has a minor revision number. In this case you can treat 2.80 as a regular number because the .80 doesn’t indicate a minor release.
Can you show me a release where the normal versioning scheme applied? They’ve never done this. Even bug fixing releases use letters instead of numbers.
There’s nothing “standard” about how blender does versioning. We all know that blender is a maverick. This just seems to be another one of those cases where the foundation is playing by its own rules.
2 is the major version 80 is the minor version
you can see the full version number (including patch number) in the bottom right corner.
You can learn more about it here:
1 Like
It would seem that I’m wrong, but not because of anything people have said here, but simply because Ton has spoken on the issue:
“Blender is almost 25 years old now, the versioning string was designed back then to be a digital number with 3 digits. It started with 1.00 and now is at 2.80. The major leaps were noted as 1.2, 1.5, 1.8, 2.0. 2.3. 2.5. and now 2.8. Just digital numbers.” - Ton Roosendaal
From this thread on bf-committer’s mailing list: https://lists.blender.org/pipermail/bf-committers/2018-December/thread.html#49696
Still, I think there is not universal agreement even among the developers as Chad Fraleigh describes in his post that Blender does use some form of semantic versioning except that the dot between the minor and patch number is dropped, which is weird, but would explain a lot of things.
Well, no sense in discussing this anymore.
Dude, this isn’t an argument over how “normal” schematic versioning works. It’s a discussion wherein people have simply pointed out that blender doesn’t use the typical versioning scheme. This isn’t a matter of opinion. like it or hate it blender so far hasn’t used a scheme you would expect. As deltaray has pointed out above me Ton Roosendaal (the founder of the project) says the version was just meant to be a digital number:
https://lists.blender.org/pipermail/bf-committers/2018-December/049704.html
But after version 3 is released, they are open to switching to another versioning scheme. I’m done arguing over this. It doesn’t really serve any point.
Not really, it has a semblance to semantic versioning, but is not actually the standardized semantic versioning scheme.