imgui-rs/docs/development-process.md

imgui-rs development process

As summarised in issue #665

In summary:

1. There is a main branch
2. For each semver compatible release there is a stable branch (e.g 0.9-stable)
3. Each patch release becomes a tagged commit on this stable branch (e.g v0.9.5 would come from a tagged commit on the 0.9-stable branch)

General process

Day to day development

1. Work on main branch
2. General PR's are submitted against the main branch

When it is time to make a new release, we create a x.y-stable branch (e.g 0.9-stable) from main

1. Ensure CHANGELOG is up to date
2. Ensure README is up-to-date (including the Dear ImGui Version in badge URL, MSRV)
3. Bump version in the various Cargo.toml
4. A stable branch is created, e.g git switch -c 0.9-stable and pushed to Github
5. Publish various crates (noting it has to be done starting with imgui-sys, then imgui, then the others)

cargo publish -p imgui-sys
cargo publish -p imgui
cargo publish -p imgui-winit-support --no-verify
cargo publish -p imgui-glium-renderer
cargo publish -p imgui-glow-renderer
cargo publish -p imgui-sdl2-support
cargo publish -p imgui-winit-glow-renderer-viewports

6. Create annotated tag v0.9.0 and push to github
7. Create Release for this version on Github
8. Update and close any relevant tickets

All further PR's are still done to main

1. If they are applicable to previous release (e.g bugfixes or non-breaking changes), they are cherry-picked back to the applicable stable branch(es)

When to bump versions in Cargo.toml

Only before publishing 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).