Plan for 0.7

[veeenu]

As of #176, there is now a breaking change to user facing API from 0.6. I want to check whether we can lump more breaking changes now to reduce the number of future minor bumps, but otherwise honestly I'm ok with a new release. It's not like minor version numbers are going to run out anytime soon.

[ruby3141]

Since current release 0.6.5 has mouse input related bug(#172, #181) whose fix is merged(#175) but not released,
I think it's good idea to release intermediate 0.6.6 including that bugfix if you're currently working on breaking changes.

Broken mainline release for 1 month is not good for users, especially newcomers.

_{BTW 0.6.6 would not affect my project. I'm currently referencing HEAD of main branch directly.}

[veeenu]

The problem is that HEAD already contains breaking changes at this point and it doesn't make sense to roll those back in order to maintain semver compatibility. I will release 0.7 soon if there are no more breaking changes ahead.

[ruby3141]

You can create tag on past commit and generate release from it.

For this time it would be simple as that because there's no other commits
in bitween 0.6.5 tagged commit f8fc75d and #175 related commit f058304.
_{or commit bddd487 which is right next to the #175 related commit. It seems it's also not a breaking change.}

(appended)
Oh I forgot about Cargo.toml package.version.
Main branch need to be rebased in order to apply version number change accordingly.🤦

[veeenu]

Yeah, that's the problem. I'm thinking for the future to not merge straight to main but using a feature branch for breaking changes. For now we'll have to go straight to 0.7.