Proposal Regarding MCprep Blender Support

[StandingPadAnimations]

Currently MCprep supports all the way back to 2.78. While backwards compatibility is a good thing, the vast majority of users upgrade when a new version is released. This makes development hard as developers have to keep older versions in mind when using the Blender API, and often times it's not so obvious which features don't work on those older versions (which is a lot of work considering a small handful of people use versions below 2.8 in the first please, let alone 2.78)

However, there is the LTS builds of Blender, which continue receiving updates for 2 years after launch.

My idea is this: guarantee backwards compatibility up to the oldest LTS build that's still maintained (as of writing, this would be 2.93). This doesn't mean that compatibility for older versions or unmaintained LTS versions have to be thrown out, it just means that features will only be guaranteed to work for whatever the oldest maintained LTS build is, and the rest is at the user's risk

Pros:

• Allows developers to take advantage of newer features
• Avoids having to write workarounds for certain features
• Makes development easier as most developers are using newer versions of Blender
• Incentivizes people to upgrade and take advantage of new Blender features

Cons:

• Having to keep track of LTS maintenance schedules
• May annoy users who don't want to upgrade or are unable to upgrade due to hardware constraints

[StandingPadAnimations]

Slight proposal change. Instead of the earliest maintained LTS build, how about the latest unmaintained LTS build (which as of writing is 2.83)

[TheDuckCow]

Thanks for outlining the idea and proposal here @StandingPadAnimations. Chiming in with some initial thoughts, happy to treat this as a discussion before coming to a final conclusion (so don't treat my following words as final).

Preface

For anyone reading this, I will make sure MCprep v3.4 will still support Blender 2.7, but given the stats and discussion below, it may be the last version to keep that support.

Some usage stats

It's good to lead these discussions in a data-drive way. See the public dashboard here, numbers of course don't reflect opted out users:

• 709 or ~5% out of ~13.0K active users over the last 90d were using Blender 2.7
• For Blender 2.8 + 2.7 combined, the user number increases to 1.4K (11%)
• Limiting to just versions of MCprep 3.3.0+ and blender 2.7+2.8: 1.0K (8.6%) of users out of 11.6K (this throws out maybe old 2.7x users who haven't even updated MCprep in a long while, and thus not benefiting from continued backwards support anyways).
  • That's 588 people still actively using recent MCprep versions and blender 2.7.
  • More people are using Blender 2.7 than Blender 2.8, which sort of makes sense as it's a bigger jump than 2.8 to 2.9.

While ~9% sounds small (for 2.7+2.8 users), that is 1 out of ~11 MCprep users potentially being forced out of not using MCprep if they cannot upgrade for whatever reason (even if it's not a good reason, it adds additional user frustration). 2.7 is used by about 5%, 1 in 20 users.

Also to compare to Blender LTS, 2.0K (16%) of users are using a version of blender older than 2.93. I definitely don't want to drop support for that many users, ie one out of ~six.

My POV

Instead of pegging backwards support to some definition of LTS by the blender foundation, let's base it off of what actual current users of MCprep are using. Let's split it by exist code (maintain longer) vs new code (can support more recent-only).

My counter proposal would be the following rules:

• Active Users should be defined as: 90d rolling users opted-in with 1+ operator call from all versions of blender (regardless of current support levels), filtered for only MCprep versions equal to or greater than the most recent release which is older than 12 months ago.
  • The logic here is to avoid biasing towards continued users of old MCprep builds (who clearly aren't likely to upgrade soon anyways), but also avoid biasing to very recent MCprep builds that may have some "noise" in data.
• MCprep overall and its already existing features should drop explicit support for any minor version of Blender (e.g. 2.81 or 3.2) when the cumulative Active Users % for that and older versions of Blender drops to below 5.0% (note the decimal, so this triggers at 4.9%)
• Only provide backwards compatibility for existing assets using the same logic.
• However, don't intentionally cut out code or compatibility checks until blender version usage drops below 1.0%, meaning e.g. we would not delete Blender Internal (ie blender 2.7) until there are fewer than 1.0% of users on 2.7.
• Never drop support for a semi-major version of blender during patch releases of MCprep
  • If 3.4 is out, then 3.4.1 should maintain the same backwards compatibility, but 3.5 could reassess.
• New code and new assets need only support the top 75% cuttoff mark.
• Should any recent change in blender mean the above constraints cause extreme burden on future development, make special case exceptions that are widely announced (but I have not seen the need for this in the history of MCprep, since the 2.6 days).

If we apply these rules rigidly to the current state of affairs for 5%:

• The most recent MCprep release just older than 12mo ago is 3.2.5, released June 8, 2021
• There are 12.6K active users per the definition above
• The 5% cutoff point would be 630 users.
• The cumulative percentage of users by blender version ascending to get under 5.0% is: Blender version 2.80.74 (2.80.75 is over that 5.0% number)
• If we then group by minor blender version, that means all of Blender 2.80 is part of the "95%" bucket, but then 2.7x is under 5% and thus implies we would drop 2.7x support as part of the upcoming 3.4 release.

And then, if we apply the logic for how far back new code/assets must support:

• 75% of 12.6K is 9,450 users, so the lower 25% cutoff is 3,150 users
• The cumulative version of blender that brings us to Blender 2.93.5
• Thus, grouping to Blender Major version (rounding down), any new code developed should be guaranteed to work in Blender 2.93 (unless the new code/assets explicitly depends on features not available in older blender versions, such as geometry nodes) so that at minimum 75% of today's users may benefit from the development (knowing over time, more of this will shift to later Blender versions too).

My initial POV

I started out writing that I didn't see a need to drop explicit support given the automated testing we have in place. The numbers above helped sway me.

However, as the owner of the repo, I'm also happy to carry the majority of the burden to verify backwards compatibility as post-review changes, while others developers only worry about recent (last ~6mo) releases of blender. This goes too for the effort of creating and QA'ing newer assets for older versions, such as the FBX conversion to bring rigs backwards. Even with the above guidance on blender version support in place, I want to ensure contributing to MCprep is not daunting or burdensome, and someone contributing code should not be slowed down by this backwards compatibility.

Allows developers to take advantage of newer features

To reiterate, new features don't need to be as backwards compatible (some effect spawners already make use of Geo nodes, 3.0+ only). This in of itself is an incentive for users to upgrade, but in the form of blocking usage of new features, versus stopping them from being able to keep using the features they already had (while also benefitting from bug fixes).

Invite for discussion

StandingPad, you are one of the contributors and active maintainers of this repo too (and thank you for that!). Would you say that really has been particularly arduous for the code you've contributed so-far? Is using the backwards-compatibility utility functions very cumbersome? Please feel free to speak openly, as it would not be a great if it truly is difficult for developers to jump in, but my perhaps biased perspective is that the testing framework and tooling take care of much of the work (and I can swoop in to adjust code to make better backwards compatible when needed).

Happy to hear additional thoughts :)

[StandingPadAnimations]

The main issue's I've been having is remembering to use the wrapper functions and also writing explicit version checks. There's also the worry that some Cycles related things have changed between 2.7x and 2.8x/2.9x/3.x

[TheDuckCow]

Thanks for the reply, here's my POV to break that down:

• remembering to use the wrapper functions:
  • I think it is fair that, going forward, contributors are not expected (or requested) to use these, but that I (as the maintainer, putting backwards compatibility on my shoulders) would add those in after merging when needed. If someone does include them though it's a bonus
• writing explicit version checks:
  • I feel this one should be minor, and could be a conversation before the contribution has - basically, if someone is working on a new version and we know it's using some new feature, I can comment in "use this function at the start of your operator". Generally shouldn't expect it to be littered about
• Changes to things like cycles:
  • This one is fair to not worry about backwards compatibility, unless the changes at hand are affecting the core prep materials (the # 1 reason people use MCprep) and it can't be simply put behind a "check version" wall. But again, as the maintainer, I can make that call and generally developers won't have to worry about it.

Do you feel these concessions would be enough? With the cycles optimizer I did ask you to put in some version checks and use some utility wrappers, but imagine in the future I didn't ask you to do that and just myself added a commit to include those on my own time.

[TheDuckCow]

Per the linked issue above, we should enshrine the new guidlines into the readme. I would refine the guidline to larger combined set of:

• Support all current Blender LTS supports
• Support all major versions of blender (e.g. 2.8, 2.9) which have over 5% of active usage on recent MCprep versions (recent defined as MCprep releases in the last rolling 365 days).
• Any further backwards compatibility is incidental but not official. Dropping of support will always be explicitly stated

By this logic, technically we should be also dropping 2.8 users at only 3%. But let's not rip that bandaide off just yet.

[TheDuckCow]

Marking this as closed, as we are essentially agreed. This will be accounted for as the MCprep dev team gets set up.