@SteffenL , this is the first in a series of PR's focussed on:

• normalising Webview's behaviours and quirks across all OS platforms
• improving the user experience.

Nothing in this PR has changed from HEAD except the bump to 0.12.1.

I feel that it is important that this is released (not just tagged) as v0.12.1 for the following reasons:

• Users should not have to rely on HEAD, which is currently a moving target. They should easily point and click at the latest release, or reference an easy URL for cloning/pulling. Having to dig down to commit references to get a fixed point in time codebase is a sub-optimal user experience.
• As versions get bumped, they can also be released, but marked as pre-release. This makes it easy for people to read the changelog and evaluate if they want to try out new versions and /or features. See an example of this on my fork.
• As we become comfortable with the stability of pre-releases, we can toggle them to the latest release.
• If something breaks for a user in a later release, it is very easy for them to revert back to an earlier release.

@citkane what about community fork? looks like author ignores this repo more than year.

Thank you for all the work you put into this sequence of PRs — I appreciate the effort!

A v0.12.1 tag sounds reasonable for the current changes since v0.12.0.

I think the existing usage of [Unreleased] and [unreleased] is fine because it's consistent with the Keep a Changelog format.

I've tried to revisit your other PRs but I don't have the capacity to review them properly due to the combined scope and volume.

I did however notice a few changes I'm hesitant about, especially without prior discussion:

• Added logging
• File moves
• Function renames
• Line endings?
• Copyright notice changes

I feel bad about rejecting PRs but I'm leaning in that direction.

On a similar note, I've tried to redesign the API and internals a number of times myself, but I was never happy with my efforts. I do however believe that there's a need for a foundational cleanup.

@Leopotam also makes a fair point; forking might be the more practical route for those who want these PRs merged. The original author/maintainers appear to have moved on, and my spare time has also been very limited for a while.