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.
In our field (3d GC) there are other programs who use nonstandard versioning to define own character.
For open source it’s definitely not common.
I don’t think it’s sensible to suddenly rename 2.8x to 3.0. Let’s start thinking of what 3.0 could be next year when the beta is stable… a discussion on changing version numbering is possible then. I like this old tradition though. We have bigger challenges than that.
Regards,
Also Pablo created video about it:
I open this thread because not everyone follow mailing lists and pablo@YT
The problem with blender versioning conventions is that over the time it lost original logic.
Right now there is: 2.XYz.s
Where “2.” part is meaningless - its rather part of a program than version number it haven ben changed for 16 years
X is most important pars meaning the ‘series’ (2.4x/2.5x-2.7x/2.8x)
Y is minor version
z is a/b/c bugfix release
ans finally there is unofficial .s development version
I think that Pablo have good points to do not change versioning right now. Also 2.80 is already adversed as 2.80 and imo it is kinda too late for change it would definitely bring user confusion
Eventually we could cut out that “2.” part, and leave just “80” since it is only meaning part. (but it would lso bring user a little confusion), but more on that later.
We could right now thing about future versioning convention.
I think that with next major step we should change that convention to something else.
I see two trends with software versioning
Quite often major version change like Firefox/Chrome do. They used to rise slowly their major version, but now version change is quite often, I remembered when change from 2 to 3 was big thing, but right now they are at 64/71
Year.minorversion.subversion, like allegorytmic/autodesk/etc
I especially like the second option because you know straight away how old is the version that you are using if you are not upgrade every few moth person.
I feel if any version naming changes are to happen, Blender should make the version meaningful, such as by using Semantic Versioning. This will give a tangible benefit to the community and should hopefully inspire addon developers to do the same.
There are many common ways to version software such as yearly (with less pronounced revision versions) such as what Adobe software uses, or simply incremental versions such as what Firefox and Chrome use. These both make sense for the fields they’re being used in - It makes sense for Adobe to release PhotoShop as ‘2018’ because it already fit with their roughly yearly release schedule and added some tangible meaning for users (being able to instantly tell how old a version is).
For software which is depended on and extended with plugins, (has an API), particularly in open source software, semantic versioning has been the standard for quite some time. It allows users and developers to instantly know what has happened in that release, whether it be fixing some bugs, adding a few new features, or revamping the system with breaking changes. It goes as far as (if it is actually used properly) allowing patch and potentially minor versions of the software as well as addons to be updated automatically without any issues.
What does change is the responsibility to name versions correctly based on what changes have been made. It suddenly becomes not okay to rename a BPY property in a minor version because it needs to change and they forgot to do it last time, and it isn’t okay to release a patch version which isn’t compatible with all previous patches of that minor version. It makes development more structured and maybe that’s a change not everyone is fond of, but I feel it would bring many benefits to both users and developers of Blender and its addons.
The fact that Blender isn’t a black box which exists in a vacuum means it requires some sort of structure to its versioning. If the current versioning is to change, I feel it should be to something which will benefit the community rather than shifting from “That’s how we’ve always done it” to “That’s how adobe does it”.