Version bump (1.1.7)

[erezsh]

Trying the new workflow of making releases as PRs, to address issue #1301, and also give other maintainers and users the opportunity to comment about new releases as they come.

I plan to push this release today, since it's just a bugfix, but next time I will also give a timeline of a week or so ahead.

Open to thoughts and comments about this.

@MegaIng @nat-n

[erezsh]

Also, should we be working from a dev branch, and create a PR when we're ready for release, or work from a v1.x.x branch, each time moving to a new one?

[MegaIng]

I think I prefer a dev branch that get's merged into master. v1.x.x style branches would make sense IMO when we are potentially releasing new versions for older subversions (i.e. if we release a bug fix for 1.1 after 1.2 has been released). I don't think this will be that necessary for lark at the moment, so there is no reason to have the infra structure for that.

[MegaIng]

This review would make a bit more sense if the change that is in to be released in 1.1.7 wasn't already in master, which I assume will be the case in the future. But anyway, the version bumps looks good :-P

[nat-n]

IMO one should release as often as there is something to release :) So it's useful to keep the process lightweight.

There are more sophisticated approaches (like using a release bot to automate releases on every change), but depending on how much you want to emphasize proper collaborative process (vs being God in your own repo) the following lightweight process may be worth considering:

1. Build up changes on development branch
2. Manually merge changes to main followed by a version bump commit
3. Use GitHub releases UI to create a release tag, update the change log, and create a discussion for the release in one step
4. Merge main back to development (usually just a fast-forward of the version bump commit)

This way the release is a minor chore that a maintainer can do any time, and there's a discussion/announcement created after the fact.