[Bf-committers] Use of semantic versioning

[Benjamin Humpherys]

Here’s my splash of paint on this bike shed: 

I think bumping to 3.0 would be appropriate because of all the backward-incompatible changes being made with the removal of BGE and BI, and that the Python API has changed enough to break nearly every single add-on out there. The addition of EEVEE, GP, UI overhaul, etc are big enough to consider this a major release, but I think breaking compatibility is the best reason for a major version jump.

> On Dec 8, 2018, at 11:45 AM, Chad Fraleigh <chadf at triularity.org> wrote:
> 
> 
> On 12/8/2018 3:58 AM, Mick Lawitzke wrote:
>> it is really awesome to see the latest development of Blender. I am super impressed and hyped for what is coming. Anyway i think there is a big flaw that also results in a problem with marketing: Your versioning numbers suggest that 2.80 is just a minor update to 2.79 and people call it 2.8 (eight) instead of 2.80 (eighty).
>> I am a software developer for 15 years now and i highly recommend you to use semantic versioning:
>> - Current version is Blender 2.79 but what if you do bugfixes on 2.79, you would not call it 2.80 right? A better approach would be to call it 2.79.0 and then a bugfix makes it 2.79.1. The current latest version might be 2.79.102 if there were 102 patches on that version.
>> - The next version would be 2.80.0. But since you worked 3 years on that and introduce so many awesome improvements and changes this is a major update and would introduce Blender 3.0.0 (Or short just Blender 3).
> 
> It does use semantic [compatible] versioning, just not in standard dot-notation. Think of it more like 2.<major><minor>[<patch>], where the leading 2 is [mostly] meaningless (similar to JDK versions 1.2, 1.3, 1.4, ... where the 1 part is basically ignored).
> 
> Blender -> "standard" dot notation examples:
> 
> 2.7 -> 2.7.0.0
> 2.70 -> 2.7.0.0
> 2.78 -> 2.7.8.0
> 2.78a -> 2.7.8.1
> 7.78b -> 2.7.8.2
> 
> 
>> From marketing perspective a "Blender 3" would have a much bigger impact than just an update from "2.79" to "2.80" which is also incorrectly called "2.8", too.
> 
> 2.8 is shorthand for 2.8x, like "version 4" is shorthand for 4.x (in standard dot notation).
> 
> 
>> In addition to that i just wanted to mention, that some big projects skipped a version to make the latest update even more obvious:
>> - Windows jumped from 8 to 10
>> - PHP jumped from 5 to 7
>> This could be an option for Blender, too, to improve the marketing even further: Jump from 2.79 to Blender 4. But in my opinion a jump to 3 would already do the job.
> 
> Ugh.. manipulative, fake version jumps is for products that care more about PR than actual quality. And it is anti-semantic versioning, since it breaks the logical/meaningful progression it was designed for (instead of projects just picking versions out of a hat, all willy nilly).
> 
> 
> Personally, I've always thought it was a little confusing, too, but for backward compatibility, that's what it is. Of course, when it eventually gets past version 2.99, there might be an opportunity to move to standard notation (e.g. 3.<minor>[.<patch>], then 4.x.x, ...) without breaking the 2.x numbering style. Another option could be to market it as "Blender 8" (where the 2.* is ignored), but still use 2.8x elsewhere (however, that is confusing just like what java/JDK did). Maybe "jumping" to version 8.x (for technical realignment, not trying-to-impress PR reasons). Really, 9.x would be the earliest this could be done since 2.8x is already so heavily ingrained. The last option would be my vote, given that 2.9x planning is probably little more than a concept at this point and could easily be made 9.x.
> 
> So there's my 2 1/2 cents on the subject. Any similarity between my thoughts and those of a raving madman may be more than just coincidental. =)
> 
> 
> -Chad
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers