Capping upper supported Blender version for MCprep

[StandingPadAnimations]

Rationale

With MCprep 3.5, we tested with a version of the Blender 4.0 alpha. Finding that MCprep 3.5 at the time worked with 4.0, we released 3.5 thinking it had 4.0 support. Fast-forward after release, and Principled V2 was merged into Blender 4.0 (at the time, still in alpha). Suddenly, MCprep no longer had support for MCprep 4.0, due to breakage in prep materials. While this is really more of an unfortunate coincidence, Blender development has recently started to up the pace of changes made. Blender 4.1 for instance no longer has the Musgrave texture node, and has merged it with the Noise texture node.

I think now it's necessary that we add a hard cap to MCprep's upper supported Blender version, and change how we determine support during development.

Determining Support

I propose that for testing and developing MCprep, we simply ignore the alpha release, and focus on the latest stable or beta (depending on if there is a beta or not). Alphas are volatile, and bound to break MCprep with a single PR, whereas betas pretty much don't break unless absolutely necessary.

For example, with the next MCprep release, for now we should only focus on Blender 4.0, not 4.1. Once Blender 4.1 enters beta, however, then we can start developing around it. This should allow for a smoother transition for MCprep with regard to new versions.

Alternatively, we could also only do the latest LTS release as the upper limit (starting with 4.3), and jump to the next LTS release when it enters beta. This may sound like a weird suggestion, but LTS releases are much more stable in terms of API changes, so we can spend more time focusing on the actual addon itself, rather than dealing with compatibility issues.

Implementing a Hard Cap

As it stands, it's easy for users to expect MCprep to be compatible with the latest release of Blender if it pops up in the UI. MCprep currently has no indicator with regard to lack of support for a version beyond what it has been developed around. Thus, I propose we add a hard cap (again, based on the latest stable or beta release) that is checked by the addon, and alert the user when they're using a version too new for MCprep.

Will this be annoying? Yes.
Is it necessary with modern Blender development? Also Yes.

While it's annoying that we have to consider a hard cap now, hopefully this should improve user experience in the end.

[StandingPadAnimations]

This felt quite dystopian to write, idk why

[TheDuckCow]

Not sure I like the idea of this - blender updates often, and often MCprep doesn't need to make any changes. It means we'd start rolling out symbolic releases just to increase the cap (I'm referring to the . The other consequence is, by saying we won't provide support, means people are less likely to report issues.. which we actually do want that (if volume is something that is truly a problem, there are other solutions we could start applying, such as more people with access to respond to issues).

I could see the linked code change being useful if it was set to something, like, blender 5.0 - but we're also already guessing as to what that major breaking version is.

So. What I'd say is, such a notification setting is probably a fair one to have so we can quickly enable when we need it and we know we don't support a particular version. But I'd have it disabled by default, as for right now our goal is to simply support everything and fix what's broken (and encourage people to tell us, so we don't miss this fact).

I think it is fair to say that, in general, things might break if users start using alpha or beta builds of blender. But I'd say that's on the user, and it'd be up to us to decide if it make sense to support things. But it's still not a bad idea for people to be aware and still encoruaged to report (or check existing reports).

[TheDuckCow]

Come to think of it further, if anything I'd say we could divert this effort into creating a remote alert notice. Something like a global value set in the firebase database which if a lookup per version of MCprep crossed with a condition field for showing certain messages. This way, if we know there's a big issue with a new blender version alpha and we decide we can't support it right away, we can at least notify about that specific thing (if it's "major enough"). This could also be overkill / the right solution for a different problem

To also amend my prior statement, I think it is worth putting in release the versions in which MCprep was tested. And don't be afraid to ammend releases to update the cap after the fact, if we know things are still working with some later released blender versions. What do you think of that counter proposal @StandingPadAnimations?

[StandingPadAnimations]

I think we could give a warning about the fact that any version above the cap wasn't part of the test suite and that users should report any issues that occur. I've modified the error message in the PR and also added a button to automatically link the user to the bug report form