Change Details

This task is a placeholder so it's on the workboard for 2.83 if we go ahead with an LTS release. @fsiddi and @dfelinto will come with a concrete proposal. Discussion is ongoing here: 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 ==== Proposed UI changes: * Change status bar from subversion to bugfix version, so `2.83.15` to `2.83.0 Beta`, `2.83.0`, `2.83.1`, ... * Change splash screen from `2.83 Beta`, `2.83`, `2.83a` to `2.83.0 Beta, `2.83.0`, `2.83.1`, .. * Download packages will be `blender-2.83.0-macOS.dmg` and `blender-2.83.1-macOS.dmg` * File exporters will write `2.83.0 Beta`, `2.83.0`, `2.83.1`, .. as the Blender version. ====Python API==== There are a few places where the Python version is used, and changes here affect API compatibility. I propose the following changes: * `bpy.app.versiong_string`: change from `2.83 (sub 15)` to `'2.83.0 Beta` and `2.83.0`, `2.83.1` (for the releases). Adding 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`: change from `(2, 83, 15)` to `(2, 83, 0)`. This would break add-ons that check the third number, however I was not able to find any add-ons that do this. * `bpy.app.version_char`: deprecated, always returns empty string. * `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. Further, it seems the only place we use this value in is `if mod.bl_info.get("blender", (0, 0, 0)) < (2, 80, 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.

This task is a placeholder so it's on the workboard for 2.83 if we go ahead with an LTS release. @fsiddi and @dfelinto will come with a concrete proposal. Discussion is ongoing here: 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` | | Download Package | `blender-2.83-macOS.dmg`, `blender-2.83a-macOS.dmg` | `blender-2.83.0-macOS.dmg`, `blender-2.83.1-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. Further, it seems the only place we use this value in is `if mod.bl_info.get("blender", (0, 0, 0)) < (2, 80, 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.

This task is a placeholder so it's on the workboard for 2.83 if we go ahead with an LTS release. @fsiddi and @dfelinto will come with a concrete proposal. Discussion is ongoing here: 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 ==== Proposed UI changes: * Change s| | Old | New | | Status bar from subversion to bugfix version, so `2Bar| `2.83.15` to `2| `2.83.0 Beta`, `2.83.0`, `2.83.1`, ...1` | * Change s| Splash screen from `2| `2.83 Beta`, `2.83`, `2.83a` to `2| `2.83.0 Beta`, `2.83.0`, `2.83.1`, ..1` | *| Download pPackages will be | `blender-2.83-macOS.dmg`, `blender-2.83a-macOS.dmg` | `blender-2.83.0-macOS.dmg` and, `blender-2.83.1-macOS.dmg` | *| File eExporters will write `2| `2.83 (sub 15)` | `2.83.0 Beta`, `2.83.0`, `2.83.1`, .. as the Blender version.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.versiongon_string`: change from | `2.83 (sub 15)` to `'2| `2.83.0 Beta` and `2, `2.83.0`, `2.83.1` (for the releases). Adding bugfix number and release cycle if in alpha or beta1` | | `bpy.app.version` | `(2, matching the splash screen83, and leaving out subversion.15)` | `(2, In the bundled add-ons83, this is only used by exporters to write the application the file was exported from.0)` | *| `bpy.app.version`: change from `(2_char` | empty string, 83`a` | deprecated, 15)` to `(2always empty string | * `bpy.app.versiong_string`: add bugfix number and release cycle if in alpha or beta, 83matching the splash screen, 0)`and leaving out subversion. This would breakIn the bundled add-ons that check the third number, however I was not ablethis is only used by exporters to find any add-ons that do thiswrite the application the file was exported from. * `bpy.app.version_char`: deprecated` This would break add-ons that check the third number, always returns empty stringhowever 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. Further, it seems the only place we use this value in is `if mod.bl_info.get("blender", (0, 0, 0)) < (2, 80, 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.