Decide on and document dev/release process

[dbr]

As per #663

We currently don't have a documented approach to how we perform releases, and doing things like backporting changes to old releases

Key points would be:

1. Stable default branch
2. Develop branch with latest unreleased changes
3. Release branches
4. Checks needed before making release
5. Steps to actual publish imgui-rs (e.g release imgui-sys, then imgui; when to bump version numbers, etc)

[MarijnS95]

As mentioned in #645 (comment) I'd recommend to name the stable branch 0.8-stable. Then either have a main/master/develop branch that becomes the future 0.9-stable.

Per maintainer preference PRs can either be submitted to one branch and manually cherry-picked to the other, or PR'd to both (in certain repos I let everyone PR to main and manually cherry-pick non-breaking changes to the latest stable branch for as long as I intend to make non-breaking feature/bugfix releases).

Then I simply create tags on those stable branches, no side-tracked hard-to-manage "release" branches. Release commits (version bumps) are pushed to the 0.x-stable branches. A separate commit is made to the main/develop branch to sort out the changelog, denoting what of the previous changes have made it into a patch release.

No "pre-release versions" like a6b61be are used unless they are published to crates.io. This makes users able use [patch.crates-io] without hand-editing versions throughout their dependency tree (typically impossible without forking/editing transitive dependencies, even if there are no breaking code changes otherwise).
For example, the only way to currently use the main imgui-rs branch in a [patch.crates-io] section is by editing all (transitive!) dependencies to point to version = "0.8.1-alpha.0", defeating the purpose of the patch section.

[dbr]

Thanks, that sounds good to me!

I'll make a PR shortly with a document writing that down. If everyone is happy with that doc then we can move on to making a 0.9 release and onwards 🥳

[dbr]

PR with propsed doc at #672

[parasyte]

FWIW, the process described in the document in the new PR is a good development strategy that I have used on several complex projects. Things do get a bit ugly when the stable branches go on for some time as main diverges more and more. It makes "just cherry-pick" infeasible after a while. It's great when that's all it takes, though!

[MarijnS95]

@parasyte Indeed, I've been running into a similar scenario with a low-level bindings crate where we're cutting down heavily on quick/successive breaking releases. As a consequence I have to pick about 98% of the changes - which are non-breaking fixes or additions only - to stable branches, to the point where I'm considering to target/merge every PR to the stable branch instead, and manually rebase the three-or-so remaining breaking-change commits (via main) on top of the stable branch every once in a while.

Alas, it depends on the project and how many breaking changes versus additive development and bugfixes it sees.

[airways]

For what it's worth, I like it, big improvement over the current situation!