Page MenuHome

LTS release version numbering
Closed, ResolvedPublicTO DO

Description

For background see:
https://code.blender.org/2020/05/long-term-support-pilot/
https://code.blender.org/2020/02/release-planning-2020-2025/
https://devtalk.blender.org/t/long-term-support-and-its-implications/12525

Proposal

Change version number for bugfix / LTS releases to use numbers rather than letters (2.83c -> 2.83.3). The subversion used for file format compatibility would be hidden from the user.

There's a few reason for this:

  • It's more standard. For example semantic versioning also uses a third number for bugfix releases.
  • a-z means we need to either set the limit at 26 releases, or we need to start using more creative combinations of characters.
  • User sometimes call "alpha" releases "a", so there already exists some confusion around the use of letters.

In Blender itself, "LTS" or "long term support" would not be part of the version number or cycle. That term would only be used on the Blender websites.

Communication

Since the subversion is already at a number higher than 0 and this number appears in the UI, resetting it to 0 will cause some confusion. However this is only in alpha/beta releases, and for the purpose of bug reporting we do not rely on this number much if at all.

So I propose that we simply start at 0 and accept the confusion that this may cause.

Starting at the current subversion number is also possible, but calling the first LTS bugfix release 2.83.16 will also be confusing in its own way.

Naming
OldNew
Status Bar2.83.152.83.0 Beta, 2.83.0, 2.83.1
Splash2.83 Beta, 2.83, 2.83a2.83.0 Beta, 2.83.0, 2.83.1
Release Packageblender-2.83-macOS.dmg, blender-2.83a-macOS.dmgblender-2.83.0-macOS.dmg, blender-2.83.1-macOS.dmg
Buildbot Packageblender-2.83-8f050b6825b8-macOS.dmgblender-2.83.0-8f050b6825b8-macOS.dmg
File Exporters2.83 (sub 15)2.83.0 Beta, 2.83.0, 2.83.1
Python API

There are a few places where the Python version is used, and changes here affect API compatibility. I propose the following changes:

OldNew
bpy.app.verson_string2.83 (sub 15)2.83.0 Beta, 2.83.0, 2.83.1
bpy.app.version(2, 83, 15)(2, 83, 0)
bpy.app.version_charempty string, adeprecated, always empty string
  • bpy.app.versiong_string: add bugfix number and release cycle if in alpha or beta, matching the splash screen, and leaving out subversion. In the bundled add-ons, this is only used by exporters to write the application the file was exported from.
  • bpy.app.version This would break add-ons that check the third number, however I was not able to find any add-ons that do this.
  • bf_info "blender" field used in add-ons to indicate the minimum supported Blender version. I have found no examples of add-ons using (2, 83, x) where x is a value higher than 0.

We could expose the subversion in another way, as a .blend file format version like bpy.app.file_format_version. I can't think of a practical example of a Python script that would need this. But I see no problem adding it if a use case comes up.

The other issue is that add-ons may want to offer compatibility with different beta versions where the API changes, and the subversion provided an (inaccurate) approximation of that. I also have not found examples of add-ons doing this, and probably it's more convenient to use e.g. hasattr() to test if API functions are available. If there is a need for this, it could always be added in 2.90 or later, as the API should not break in the LTS.

Event Timeline

Brecht Van Lommel (brecht) changed the task status from Needs Triage to Confirmed.Apr 24 2020, 5:22 PM
Brecht Van Lommel (brecht) triaged this task as High priority.
Brecht Van Lommel (brecht) created this task.

I created an implementation of this in D7748: Blender: change bugfix release versioning from a/b/c to .1/.2/.3, to fully understand the implications.

Of course this proposal is not accepted at this point, so we still have to decide if we actually want to go ahead with this.

Hi @Brecht Van Lommel (brecht), I think it is better if we have the .0 there to remove ambiguity. So we can use 2.83, 2.90, ... to refer to the "product", and 2.83.0, 2.83.1, 2.90.0 to refer to specific versions of it.

I talked to @Francesco Siddi (fsiddi) yesterday he agrees (due to different reasons though - alignment/design). Also asked @Ton Roosendaal (ton) and he trusts us to decide that.

LGTM, also fine to hide subversion from Python API - exposing only if there is some important use-case for this.