Homebrew formula clashes with formula produce by Boot 4.1

[muescha]

The spring-boot.rb Homebrew formula in spring-io/homebrew-tap tracks
both the 3.5.x maintenance line and the 4.0.x line in the same formula
file. The spring-builds bot alternates between the two lines on
nearly every release, sometimes upgrading to the 4.x line first and
then reverting to 3.x shortly after, and sometimes the other way
around, for example:

• 2026-06-25: Upgrade to Spring Boot 3.5.16
• 2026-06-10: Upgrade to Spring Boot 4.1.0 → then Upgrade to Spring Boot 4.0.7 → then Upgrade to Spring Boot 3.5.15
• 2026-04-23: Upgrade to Spring Boot 4.0.6 → then Upgrade to Spring Boot 3.5.14
• 2026-03-26: Upgrade to Spring Boot 3.5.13 → then Upgrade to Spring Boot 4.0.5
• 2026-03-19: Upgrade to Spring Boot 4.0.4 → then Upgrade to Spring Boot 3.5.12
• 2026-02-19: Upgrade to Spring Boot 3.5.11 → then Upgrade to Spring Boot 4.0.3
• 2026-01-22: Upgrade to Spring Boot 3.5.10 → then Upgrade to Spring Boot 4.0.2

Full commit history: https://github.com/spring-io/homebrew-tap/commits/main/spring-boot.rb

Because the formula only ever points at a single URL/version at a time,
the outcome of brew install spring-boot or brew upgrade depends
entirely on which of the two lines the bot last committed at the
moment the user runs the command — not on any explicit choice by the
user. Two users installing on different days can end up with a 3.x or
a 4.x CLI without ever intending to pick a specific major version.

Since Homebrew never downgrades a formula automatically, this also
means a user who happens to install while the formula points at 4.0.x
stays on that version indefinitely once the bot flips back to 3.5.x,
since brew upgrade will not revert them to a "lower" tracked version.
brew info then reports the 3.5.x line as current/stable while the
installed keg silently remains on 4.0.x, with no indication that this
happened due to timing rather than intent.

Suggested fix: split the formula into two, following the standard
Homebrew convention for parallel major release lines, e.g.:

• spring-boot → tracks the primary/latest line
• spring-boot@3 → tracks the 3.x maintenance line

This would let users explicitly choose which major version to install
and upgrade, instead of the outcome being determined by upgrade timing.

Happy to provide more detail or help test a fix if useful.

[wilkinsona]

Thanks for noticing and reporting this. We used to release serially from oldest version to newest (e.g. 3.5.x, then 4.0.x, then 4.1.x) so the latest version would ultimately win. We now release in parallel resulting in the problem that you've observed.

Boot 3.5.x is out of OSS support, but we still have a problem with 4.0.x and 4.1.x if we release in parallel. I think we should address this by having versioned formulae but split things on minor version (as homebrew/core does with MariaDB, for example). Given that support for Boot 3.5 has only just ended and to help with upgrades to its last OSS release (3.5.16), I think we should have three formulae:

• spring-boot.rb (4.1.0 at the time of writing)
• spring-boot@4.0.rb (4.0.7 at the time of writing)
• spring-boot@3.5.rb (3.5.16)

We could make a one-off change to spring-io/homebrew tap to straighten things out and then update the 4.0.x branch here to produce the spring-boot@4.0.rb formula in future releases.

[GollapudiSrikanth]

Thanks for outlining the approach.

I'd be happy to work on this. My understanding is that the change would update the 4.0.x release process to generate a versioned spring-boot@4.0.rb formula, while the one-off changes for spring-boot.rb and spring-boot@3.5.rb would be handled in the Homebrew tap.

If that matches the intended direction, I'd be glad to take it on.

[wilkinsona]

Thanks for the offer, @GollapudiSrikanth. I already have some changes locally for the Tap and, given that this needs to be coordinated across to repositories, I think it's better if the core team takes care of it.