TheDuckCow
Upgrade minimum Blender version to 3.x
To be reviewed further, we are contemplating which new minimum version of Blender to support. It's split between 3.0, 3.3, and 3.6 in terms what limits it places on development, as well as how much we can redesign the overall experience (though with current plans, that might be more appropriate to wait until we set 4.x as a minimum).
This issue is more for giving a heads up to any users that in some future more notable version, such as MCprep 3.8, that we will be dropping 2.8 and 2.9 support officially.
Looking into our options, here's what each version would entail:
- Blender 3.0 would give us Python 3.9
- Blender 3.3 would give us Python 3.10
- Blender 3.6 would give us Python 3.10
Personally, based on the results of grep "min_bv|bv30" MCprep_addon, I'm of the opinion that Blender 3.6 would be the best option, with 3.3 as a compromise if the amount of users remaining on 3.3 by MCprep 3.8 is still significant. Out of the 10 times we call min_bv (ignoring its use in wrappers like bv30, as well as rig spawning since those are based on file names). all of them are for Blender 3.4 or above, so by having our minimum at Blender 3.6, we have a lot of room for cleaning up some code paths that are no longer necessary. Even with Blender 3.3 as a minimum however, we still can do some cleanup with 2.8X and 2.9X codepaths.
Blender 3.0 however, in my view at least, isn't a good contender as a new minimum, mainly due to the Python version. Out of the 3 options, it's the only one that isn't using a minimum of Python 3.10*. Even among the entire 3.X series, Blender 3.1 uses Python 3.10, so we'd effectively be restricting ourselves from Python 3.10 features for just one release in the 3.X series.
*This gets a bit weird with Blender 3.6, as there was a build option to compile it with Python 3.9 support as to comply with VFX Reference Platform 2022. However, this was mainly there for studios who wanted to use Blender 3.6 as an LTS, while having VFX Reference Platform compliance (and thus wasn't part of the official builds from the Blender website), and by the time Blender 4.0 came out, VFX Reference Platform 2023 already mandated Python 3.10. IMO, we don't really need to worry about this particular edge case, as it's highly unlikely that someone in the MC animation space A. compiled Blender 3.6 from source with B. the option for VFX Reference Platform 2022 compliance and C. will still be using that build by MCprep 3.8
Data time: Ok this took me a minute to put together, but here's the hard numbers on the new installer and ongoing userbase considering all users and all versions of MCprep:
With the above chart, we can see in the most conservative case (going based off of the graph to the right on users, rather than just new installs on the left) there are just under 5% of users on a version older than 3.6, at 4.74% (and 2.66% would be dropped if we set Blender 3.3 as the min)
If we add a filter for MCprep's latest version (which has been out for quite some time, ie anyone who would prone to updating likely already has, and thus would be in the pool relevant for future releases) then ... actually, it doesn't look that different. Seems like even new users are installing MCprep into really old Blender versions rather than just those users who are "hanging on". But most importantly, if we were to switch to 3.6, we'd be dropping off about 3.52% of the userbase (or 1.96% dropped if going with a 3.3 minimum)
Numbers on the usage chart on the right can be over 100%, implying some users had activity in more than one version of Blender during the period
On dev implications
The other angle to consider is what options we are afforded by increasing the min version. One of the big plays, in my mind, is trying to move to an asset browser focussed version of MCprep. Though it has evolved over time, I'd argue the minimum we need is collection support for rigs to work. Given that was introduced in Blender 3.2, assigning 3.3 as a minimum would still be functional for that goal ultimately. We don't get post-drop asset browser handlers from the asset browser until later Blender 4.x versions (was that 4.3? I don't remember), so we'd still have to design for a base experience even without that in mind (in case we use this handler as a way to essentially represent "virtual" representations in the asset browsers, to avoid pregeneration and tagging of all assets, which would be... a big pain).
So, based on that, I personally would advocate for setting 3.3 as a minimum, as we're talking less than 2%, we're nearly doubling the number potentially affected by setting the min to 3.6 without substantially changing implications of new dev. Regarding legacy code, yes there's more we could delete, but it's also not changing that much I'd argue, not much time being lost on dev there.
Let me know if you concur with this conclusion @StandingPadAnimations
Assuming these stats remain roughly the same by MCprep 3.8 (probably will, but who knows), I think 3.3 would be a good minimum to start planning for
As noted in https://github.com/Moo-Ack-Productions/bpy-build/pull/25, BpyBuild 0,6 will be using Python 3.10. Since we plan to update the minimum supported release to Blender 3.3 anyway (which uses Python 3.10), it might be best to delay the upgrade to BpyBuild 0.6 here on the MCprep repo until MCprep 3.8, as to avoid having too much of a gap between the Python version used by MCprep and the Python version used by BpyBuild