what if i bump: dev tool to help with changelog edits

[Madoshakalaka]

what-if-i-bump is added: a dev CLI tool that computes semver cascade for the gloo workspace. Given a crate and bump level (patch, minor, major), it walks the internal dependency tree and reports exactly which CHANGELOG.md sections need to be added or renamed, following the cascading rules from CONTRIBUTING.md.

I also normalized the existing CHANGELOG.md: remove quoted version numbers, prefix all section headers with gloo-, add a top-level gloo section, remove the standalone worker-macros section (it is a companion of gloo-worker).

Example

$ what-if-i-bump utils minor

Bump cascade:

  gloo-utils    0.3.0   =>  0.4.0 (zero-minor-bumping)  (target)
  gloo-console  0.4.0   =>  0.5.0 (zero-minor-bumping)  [depends on gloo-utils]
  gloo-history  0.3.0   =>  0.4.0 (zero-minor-bumping)  [depends on gloo-utils]
  gloo-net      0.7.0   =>  0.8.0 (zero-minor-bumping)  [depends on gloo-utils]
  gloo-storage  0.4.0   =>  0.5.0 (zero-minor-bumping)  [depends on gloo-utils]
  gloo-worker   0.6.0   =>  0.7.0 (zero-minor-bumping)  [depends on gloo-utils]
  gloo          0.12.0  =>  0.13.0 (zero-minor-bumping)  [depends on ...]

CHANGELOG.md edits:

  ## `gloo-utils`  -- add at top:
    ### Version 0.4.0

  ## `gloo-console`  -- add at top:
    ### Version 0.5.0
    - Bump `gloo-utils` to 0.4.0
  ...

$ what-if-i-bump net patch

Bump cascade:

  gloo-net  0.7.0                =>  0.7.1 (patch-bumping)  (target)
  gloo      0.12.0               =>  0.12.1 (patch-bumping)  [depends on gloo-net]

CHANGELOG.md edits:

  ## `gloo`  -- add at top:

    ### Version 0.12.1

    - Bump `gloo-net` to 0.7.1

  ## `gloo-net`  -- add at top:

    ### Version 0.7.1

say there is already a gloo-net 0.7.1 and a gloo 0.12.1 section accumulating changes:

$ what-if-i-bump net patch

   Compiling what-if-i-bump v0.1.0 (/home/maa/Projects/gloo/tools/what-if-i-bump)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.15s
     Running `target/debug/what-if-i-bump net patch`
Bump cascade:

  gloo-net  0.7.0 (-> 0.7.1)         (already satisfied)  (target)
  gloo      0.12.0 (-> 0.12.1)       (already satisfied)  [depends on gloo-net]

All required CHANGELOG sections already exist. Add your changes there.

Design notes

• *-macros crates (currently only gloo-worker-macros) are tracked in the dependency graph but have no CHANGELOG section. The tool directs their changelog suggestions to the parent crate's section (e.g., gloo-worker).
• Running with no arguments prints current status of all crates (level vs bumping).

$ what-if-i-bump

Current crate status:

  gloo                0.12.0  patch-bumping (-> 0.12.1)
  gloo-console        0.4.0  level
  gloo-dialogs        0.3.0  level
  gloo-events         0.3.0  level
  gloo-file           0.4.0  level
  gloo-history        0.3.0  level
  gloo-net            0.7.0  patch-bumping (-> 0.7.1)
  gloo-render         0.3.0  level
  gloo-storage        0.4.0  level
  gloo-timers         0.4.0  level
  gloo-utils          0.3.0  level
  gloo-worker         0.6.0  level
  gloo-worker-macros  0.2.0  (companion of gloo-worker)

Usage: what-if-i-bump <crate> <patch|minor|major>
Example: what-if-i-bump net minor

[ranile]

This needs a README to document how to use the tool. It would also be nice to have the script also update the changelog automatically (and a --dry-run flag to opt out of writing)

[ranile]

It would be nice to have better error handling with eyre, but not hard blockers as this tool shouldn't need to be run by everyone

I think eyre is better than anyhow for these kind of tools because it produces prettier output with color_eyre

[ranile]

nit: Option::and_then can save us from nested if lets

[Madoshakalaka]

I actually have doubt on the correctness of the current suggestions.

say there is a bug fix in gloo-utils that warrants a patch version bump. This tool right now will suggest a patch version bump in gloo-console too because of the dependence on gloo-utils. But what if the way gloo-console uses gloo-utils isn't related to the bug fix at all?

Further more, if gloo-utils adds a feature (say a new function) which warrants a minor version bump. This tool right now will suggest a minor version bump in gloo-console too, even when gloo-console doesn't use the new function at all.

What if we use agentic AI tooling to help with the suggestions? Is it an overkill?

[ranile]

Good points. There's https://github.com/crate-ci/cargo-release and I briefly used it for gloo in the past. What do you think of adopting it fully instead of rolling our own tool? We can use have a tool for changelog like https://github.com/yewstack/yew/tree/master/tools/changelog