-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal Regarding MCprep Blender Support #319
Comments
Slight proposal change. Instead of the earliest maintained LTS build, how about the latest unmaintained LTS build (which as of writing is 2.83) |
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). PrefaceFor 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 statsIt'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:
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 POVInstead 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:
If we apply these rules rigidly to the current state of affairs for 5%:
And then, if we apply the logic for how far back new code/assets must support:
My initial POVI 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.
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 discussionStandingPad, 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 :) |
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 |
Thanks for the reply, here's my POV to break that down:
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. |
Per the linked issue above, we should enshrine the new guidlines into the readme. I would refine the guidline to larger combined set of:
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. |
Marking this as closed, as we are essentially agreed. This will be accounted for as the MCprep dev team gets set up. |
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:
Cons:
The text was updated successfully, but these errors were encountered: