Dropping 2.7x support in MCprep 3.5

[TheDuckCow]

MCprep has an incredible track record of supporting a wide range of blender versions - but at the cost of somewhat slower release cycles. One of the reasons for slower release cycles is the burden of cross version blender QA that needs to be done. How incredible is this track record of support? As of March 2023, we currently support Blender 2.79 (released Sept. 2017) through 3.5. That represents a range of support covering 6 years of blender versions, far beyond Blender's own LTS. But it's time to update our cuttoff point.

As the title suggest, the intention is to drop Blender 2.7x support in the next major (3.5) version of MCprep.

Rationale

See my much more detailed posts about stats over here. At that time (July 2022), 2.7x users made up about 5% of all users. That has since dropped to only 3% who looking at all versions of blender & MCprep. Here is the current 90d figure based on usage of opted in users (usage is a good indication).

However, if I filter for only the latest 3 releases (MCprep 3.4+), I see 2.7x users are only 2.49% of the overall userbase. This is significant because this means at least some of the 2.7x users of older MCprep versions likely aren't seeking to upgrade to new versions anyways. And the effort going into trying to continue supporting these 2.5% of users could be better spent on other initiatives (like translations for instance, or tools which increase code dev velocity like typing).

What about Blender 2.8 and 2.9?

We will continue to support them, but with the attempts to follow a similar methodology as here. Not all features will work be enabled in 2.8 and 2.9, especially as MCprep evaluates how to better support and integrate with the Blender Asset Browser.

What changes once 2.7x is dropped

• Users who want to continue using MCprep in blender 2.7 are free to do so, they just won't get any updates or bug fixes. Older versions remain available to download here
• All new rigs will start being saved in Blender 2.80, skipping a rather arduous backporting process to 2.7x
• 2.8x support will continue to be maintained.
• Python typing annotations will become standard practice (but added incrementally) (see reference here, via @StandingPadAnimations )

This is not happening tomorrow, or the next month. But it's coming nearer. Keep an eye on the 3.5.0 release cycle.

[StandingPadAnimations]

This also means:

• We can move from os to pathlib, since as Python 3.6, functions in os can take in Path objects. This means we can make filepaths more readable.
• Fstrings, making formatting easier for new programmers
• Dataclasses
• Caching
• etc

[TheDuckCow]

Wow, didn't even realize dataclasses weren't a thing in py2 (I use them all the time at work). F strings also a great thing, yup there will be a lot of goodies to come.

[StandingPadAnimations]

Wow, didn't even realize dataclasses weren't a thing in py2 (I use them all the time at work).

Yeah they were added in Python 3.7, which is what Blender 2.8 uses

[StandingPadAnimations]

Users who want to continue using MCprep in blender 2.7 are free to do so, they just won't get any updates or bug fixes.

Just for anyone interested, one could also fork MCprep for 2.7x support, but this isn't advisable, especially as we start to use more and more Python 3.7+ features. There really isn't much of a reason (beyond hardware compatability, though even that's a bit of a stretch in 2023) to not use modern versions of Blender, especially with the option to use 2.7x keybinds

[StandingPadAnimations]

I know we're pretty deep in the MCprep 3.5 development cycle but I think we should try and make 3.5 at least mostly focused on bug fixes. We rarely get the chance to have a full development cycle that goes through all of the MCprep code and I think we should take advantage.

I also have an idea regarding future development cycles (based on Blender's BCON system). Currently we don't really know when an MCprep development cycle is finished and we just accept all pull requests for the next release, so starting with 3.5.1 I think we should adopt something like the following (all "deadlines" are soft, and this is by no means final):

This new system would give us a good idea of how far along we are in MCprep development, and would allow us to time MCprep beta releases accordingly (if we decide to start doing betas)

EDIT: There's the question of "how do we know what stage we're on?". For that, I think it would make sense to have a "master" pull request for dev to master that contains all of the updates. We already have to do that anyway at the end of a development cycle, so we can make it early and have it act as a development updates "channel" so to speak

[TheDuckCow]

Would be great to have v3.5.0 have all of these warnings cleared up before the release, as right now it makes the console rather messy:

  File "/Users/patrickcrawford/Library/Application Support/Blender/3.6/scripts/addons/MCprep_addon/spawner/spawn_util.py", line 561, in load_append
    if not util.bv28():
  File "/Users/patrickcrawford/Library/Application Support/Blender/3.6/scripts/addons/MCprep_addon/util.py", line 227, in bv28
    env.deprecation_warning()
  File "/Users/patrickcrawford/Library/Application Support/Blender/3.6/scripts/addons/MCprep_addon/conf.py", line 202, in deprecation_warning
    traceback.print_stack()

[StandingPadAnimations]

@TheDuckCow I'm currently removing the last of the deprecated functions, do you have a full log I could use to determine what functions are being called and where?

EDIT: these deprecation warnings should only appear in dev builds, but if they also appear in production builds then I'll fix that. I don't expect we'll make it through all deprecated functions by 3.5, but over time in future releases there should be less and less

[TheDuckCow]

Oh oof I've got a branch locally. Give me a few minutes to push so you can see where I'm add, I've been doing some cleanup in parallel to remove old code branches.

[TheDuckCow]

Branch name is 399-update-deprecated-references @StandingPadAnimations but I know it's not in a fully working state right now, working on creating another unit test because ahem the tests should do better at proactively seeing it's broken (I see I didn't get the meshswap tests migrated).

Oh and it's not that the deprecation warnings are any issue, it's more that any use of utils.bv28() is entirely pointless now, so I'm just removing all of the code branches related to 2.7x based off of that.

[TheDuckCow]

Closing, as we are about to release. 2.7 support officially dropped in 3.5.