Are tests a bugfix or a new feature?

It is not so clear with regards to versioning. Somehow it could go into 3.6.1 because it improves the docs and doesn't modify any library code, but I do not think it is clear if it should. I was actually thinking of splitting into two PRs so that the examples can be updated in 3.6.x.

I put on call agenda to clarify & then we can maybe update docs (I think it's a perennial mystery)

I do not think we should backport this sort of thing in general. There is always a risk of the docs / tests accidentally using a new feature.

I think our effort is better spent hitting our 6mo minor release target than backporting every thing that is backport-able.

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

git checkout v3.6.x
git pull

2. Cherry pick the first parent branch of the this PR on top of the older branch:

git cherry-pick -x -m1 3263cfc5bae36cd2306d8dc9fcc37fbad0eefb92

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

git commit -am 'Backport PR #23865: Add test and example for VBoxDivider'

4. Push to a named branch:

git push YOURFORK v3.6.x:auto-backport-of-pr-23865-on-v3.6.x

5. Create a PR against branch v3.6.x, I would have named this PR:

"Backport PR #23865 on branch v3.6.x (Add test and example for VBoxDivider)"

And apply the correct labels and milestones.

Congratulations — you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon!

Remember to remove the Still Needs Manual Backport label once the PR gets merged.

If these instructions are inaccurate, feel free to suggest an improvement.

🤦 I forgot that this was tests and that needs two approvals oops

No strong reason to do a manual backport here.