LTS release version numbering #76058

New Issue

Brecht Van Lommel · 2020-04-24T17:22:30+02:00

Brecht Van Lommel commented

2020-04-24 17:22:30 +02:00

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

	Old	New
Status Bar	`2.83.15`	`2.83.0 Beta`, `2.83.0`, `2.83.1`
Splash	`2.83 Beta`, `2.83`, `2.83a`	`2.83.0 Beta`, `2.83.0`, `2.83.1`
Release Package	`blender-2.83-macOS.dmg`, `blender-2.83a-macOS.dmg`	`blender-2.83.0-macOS.dmg`, `blender-2.83.1-macOS.dmg`
Buildbot Package	`blender-2.83-8f050b6825b8-macOS.dmg`	`blender-2.83.0-8f050b6825b8-macOS.dmg`
File Exporters	`2.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:

	Old	New
`bpy.app.verson_string`	`2.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_char`	empty string, `a`	deprecated, 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.

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** | | Old | New | | -- | -- | -- | | Status Bar| `2.83.15` | `2.83.0 Beta`, `2.83.0`, `2.83.1` | | Splash | `2.83 Beta`, `2.83`, `2.83a` | `2.83.0 Beta`, `2.83.0`, `2.83.1` | | Release Package | `blender-2.83-macOS.dmg`, `blender-2.83a-macOS.dmg` | `blender-2.83.0-macOS.dmg`, `blender-2.83.1-macOS.dmg` | | Buildbot Package | `blender-2.83-8f050b6825b8-macOS.dmg` | `blender-2.83.0-8f050b6825b8-macOS.dmg` | | File Exporters | `2.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: | | Old | New | | -- | -- | -- | | `bpy.app.verson_string` | `2.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_char` | empty string, `a` | deprecated, 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.

Brecht Van Lommel commented

2020-04-24 17:22:30 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Brecht Van Lommel commented

2020-04-24 17:22:30 +02:00

Added subscribers: @fsiddi, @dfelinto, @brecht, @jesterking

Brecht Van Lommel commented

2020-05-15 20:48:57 +02:00

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.

I created an implementation of this in [D7748: Blender: change bugfix release versioning from a/b/c to .1/.2/.3](https://archive.blender.org/developer/D7748), 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.

Dalai Felinto commented

2020-05-20 10:54:13 +02:00

Added subscriber: @Ton

Dalai Felinto commented

2020-05-20 10:54:13 +02:00

Hi @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 @fsiddi yesterday he agrees (due to different reasons though - alignment/design). Also asked @Ton and he trusts us to decide that.

Hi @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 @fsiddi yesterday he agrees (due to different reasons though - alignment/design). Also asked @Ton and he trusts us to decide that.

blender-admin commented

2020-05-25 10:49:04 +02:00

This issue was referenced by a86b5df005

This issue was referenced by a86b5df005d0c474de973215b112f404902b2607

Campbell Barton commented

2020-05-28 09:59:10 +02:00

Added subscriber: @ideasman42

Campbell Barton commented

2020-05-28 09:59:10 +02:00

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

Brecht Van Lommel commented

2020-05-29 17:58:55 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Brecht Van Lommel closed this issue

2020-05-29 17:58:55 +02:00

Brecht Van Lommel self-assigned this 2020-05-29 17:58:55 +02:00

blender-admin commented

2020-05-29 19:15:35 +02:00

This issue was referenced by infrastructure/blender-buildbot-www@d187dd6f43

This issue was referenced by infrastructure/blender-buildbot-www@d187dd6f435cedb2f262c38825b05a354968f51b

blender-admin commented

2020-05-29 21:03:00 +02:00

This issue was referenced by blender/blender-addons@f5edd05a3b

This issue was referenced by blender/blender-addons@f5edd05a3b19a8b9647720673c5b327863df891d

blender-admin commented

2020-06-25 14:51:55 +02:00

This issue was referenced by 2b9ac1de49

This issue was referenced by 2b9ac1de491142508212471fb8e1d2cbdd655914

ronsn commented

2020-06-30 23:28:46 +02:00

Added subscriber: @ronsn

ronsn commented

2020-06-30 23:28:46 +02:00

@brecht , @dfelinto Since you changed the versioning system and bpy.app.version returns now a different result than bpy.data.version there are several programs that don't work anymore because of a mismatch.
Now you didn't silently only change the API description for bpy.data.version but also the meaning which it had since forever. That's now why the programs don't work anymore.
So my question is: Is there another way to get the Blender version a .blend file was saved with?

@brecht , @dfelinto Since you changed the versioning system and `bpy.app.version` returns now a different result than `bpy.data.version` there are several programs that don't work anymore because of a mismatch. Now you didn't silently only change the API description for `bpy.data.version` but also the meaning which it had since forever. That's now why the programs don't work anymore. So my question is: Is there another way to get the Blender version a .blend file was saved with?

Brecht Van Lommel commented

2020-07-01 11:32:28 +02:00

@ronsn, which programs don't work anymore?

The major and minor version in bpy.data.version still tell you the Blender version the file was saved with. And in general I would not expect the patch version of Blender to make any difference regarding .blend file contents, so if the file was saved with 2.83.0, 2.83.1, 2.83.2, ... should not matter?

@ronsn, which programs don't work anymore? The major and minor version in `bpy.data.version` still tell you the Blender version the file was saved with. And in general I would not expect the patch version of Blender to make any difference regarding .blend file contents, so if the file was saved with 2.83.0, 2.83.1, 2.83.2, ... should not matter?

ronsn commented

2020-07-01 21:55:22 +02:00

@brecht About the programs which don't work anymore:
1.) One program that doesn't work anymore is "THE VIDEO EDITOR'S RENDER SCRIPT". But which is no longer being developed. It stopped working the day Blender 2.83 was released^^

2.) The other program/programs is.... okay the story in brief: Some time ago, my colleague asked me if there would be problems with Blender if the announced change of the versioning system was completed because his customer had set up an infrastructure where Blender is also used. There, among other things, the version of .blend files is compared and then the corresponding version of Blender is started or in case of issues/bugs/blacklist another version is started. No idea what exactly happens there. Anyway, I looked at Blenders documentation and your official announcements and it just said that you are changing the versioning system. So there shouldn't be any problems to compare the versions anyway. So I told my colleague and he told his customer. I don't know which programs they use, or how they call them. Their setup/infrastructure was made by someone in the past so I can't tell you anything about that. But they just don't work anymore. And now guess who is the idiot now? 😁

But apart from that: I think the exact version plays a role, because they blacklisted certain versions. At least as I understood it.

@brecht About the programs which don't work anymore: 1.) One program that doesn't work anymore is "THE VIDEO EDITOR'S RENDER SCRIPT". But which is no longer being developed. It stopped working the day Blender 2.83 was released^^ 2.) The other program/programs is.... okay the story in brief: Some time ago, my colleague asked me if there would be problems with Blender if the announced change of the versioning system was completed because his customer had set up an infrastructure where Blender is also used. There, among other things, the version of .blend files is compared and then the corresponding version of Blender is started or in case of issues/bugs/blacklist another version is started. No idea what exactly happens there. Anyway, I looked at Blenders documentation and your official announcements and it just said that you are changing the versioning system. So there shouldn't be any problems to compare the versions anyway. So I told my colleague and he told his customer. I don't know which programs they use, or how they call them. Their setup/infrastructure was made by someone in the past so I can't tell you anything about that. But they just don't work anymore. And now guess who is the idiot now? 😁 But apart from that: I think the exact version plays a role, because they blacklisted certain versions. At least as I understood it.

Brecht Van Lommel commented

2020-07-01 22:11:09 +02:00

The video editors render scripts appears to have been updated around the time of the 2.83 release:
https://github.com/mikeycal/the-video-editors-render-script-for-blender/

It's unfortunate we didn't catch this bpy.data.version issue at the time of the 2.83 release and document it in the release notes, but changing it now would break compatibility again.

The video editors render scripts appears to have been updated around the time of the 2.83 release: https://github.com/mikeycal/the-video-editors-render-script-for-blender/ It's unfortunate we didn't catch this `bpy.data.version` issue at the time of the 2.83 release and document it in the release notes, but changing it now would break compatibility again.

Thomas Dinges added this to the 2.83 LTS milestone 2023-02-08 16:38:04 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

LTS release version numbering #76058