We wanted to select an extruder based on wether or not it has support-material, so that the user doesn't have to think about selecting a support extruder any more and in most cases, can't forget anymore either. The formula present in fdmprinter to do that was not only an unreadable nightmare, but also very slow. We decided to pull most of that functionality into the settings-function machinery instead (but just a bit more generic so other properties can be selected, not just 'material_is_support_material').
done as part of finishing off CURA-10643
We're not sure why this introduces a boatload of small segments into the infill, and we're out of time to try and fix this before the beta. Re-introducing after the beta seems like a bad idea, so this'll have to wait until 5.5 unfortunately.
Done as part of fixing for CURA-10500, but for the original Small Skin Area feature, see CURA-10201. For the ticket to (fix? and) reintroduce the feature, see CURA-10670.
Rest Preference
"Force Only Buildplate" can be "On Buildplate when possible",
Because Support can be created everywhere but as much as possible starting from the buildplate and in some case we can have some support starting from the model..
"On Model If Necessary" can be "On Model If required",
Because support can be created everywhere and if required you can have support starting on the model. And Sometimes Required means they start on the model because you have more direct or simple support if you start on the model.
As suggested by @5axes
We determine the version of a conan package based on a Git tag and then count the number of commits between the last tag
and the current tag to get the +testing_6 or +testing_13 after the alpha/beta designation etc.
This will give us logical sequential numbers with which we can determine which version was later.
But the method can't take into account tags created on release branches, a branch parallel to the main branch, once
these are merged, after a tag then suddenly the first tag it encounters is closer then it was before, this means that we
then accidentally create a second package with the same version and this starts tripping things up.
Now these logical statements aren't necessary to determine the latest version, according to semver everything after the
+ is ignored and both versions should be compatible.
An easy fix is to replace the testing_<no_of_commits_since_last_tag> with testing_<commit_hash> that way we don't have
two conan packages created from different commits anymore, which is the most common root cause of our problems in this
flow.
