Roll back API changes ahead of interim release

[taion]

This reverts commit d2af254522cba7f36c9980852801e66a98fe3e70.

[timdorr]

Can we just create a 1.1.x branch and let master be the latest and greatest bleeding-edge stuff? We treat 0.13.x as a support release branch, so we can use 1.1.x the same way and keep things consistent.

[taion]

We could do that; the interim-release branch (minus the top 2 commits, or with them) would be a clean starting point.

However, we do need to do stuff like update the changelog and the docs even for a v1.1.x release. I feel like it'd be marginally less work just to re-apply the API change commit. Otherwise we'd need to cherry-pick those docs updates.

[timdorr]

Except you'll have to update this "undo patch" of sorts against any further changes in master, which may create more conflicts as it diverges. That seems to me like a lot more work. Merge conflicts vs. copy-pasting some markdown? I can do that by hand if need be.

Let me push up a 1.1.x and let me know what you think.

[taion]

We pick our poison either way. interim-release~2 is a clean 1.1.x branch if you want - has just the commits we need.

[timdorr]

Let's cherry pick in commits and copy-paste any docs changes. Less history noise from reverting commits and such. Plus, contributors gets the right authorship (gotta fill the profile dot graph! 😄)

[taion]

Sure - I've already done that on the branch though - no need to do so again

[timdorr]

I think we did it differently. I did an interactive rebase, so I got the real commits instead of the merge commits. Maybe different settings? Anyways, the end result is the same. It's all good 👌

[taion]

That's fine then - as long as the file content matches. Real commits probably better. Good to have a double check.