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. 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.