Proposal: Add a Stable Release Channel

[rdself]

Hi @diegosouzapw ,

First of all, thank you for the work you and other contributors have been putting into OmniRoute.

I’m genuinely happy to see how actively this project is evolving, and I’m also glad to be able to contribute to it. In my view, OmniRoute has become the most feature-complete open-source AI routing/proxy projects available today. I’ve recommended it to many friends for exactly that reason.

At the same time, some of those friends have recently shared a concern that I think is worth discussing: the project moves very quickly, with frequent releases and a steady stream of new providers and features. While that pace is impressive, for some users it also makes the experience feel less predictable than they would like. In practice, they often do not need every new provider or capability, and they would prefer a more stable experience with fewer regressions and less operational churn.

Because of that, I’d like to propose adding a stable release channel.

What I have in mind is something along these lines:

• Keep the current fast-moving release flow for users who want the latest features as soon as possible.
• Add a separate stable channel that only receives releases after more complete testing and validation.
• Aim for a more restrained release cadence for stable, ideally around one release per month.
• Be more conservative about what lands in stable, especially when it comes to newly added providers or broader feature surface area.

I think this could help the project serve two different groups of users at the same time:

• users who want rapid innovation and are happy to follow fast updates
• users who mainly want reliability, predictability, and a setup they can recommend or deploy with more confidence

I also understand that this would affect the overall project workflow, release process, and maintenance burden, so I’m not presenting this as a simple request with an obvious answer. I’d be very interested to hear your thoughts, as well as feedback from other contributors and users.

[diegosouzapw]

Hey @rdself!

Thank you for this well-thought-out proposal! We completely agree that stability is important, especially for production deployments.

This idea is already tracked internally as Issue #1166 in our feature backlog. We are planning to implement a stable release channel alongside our current rolling release model.

In the meantime, here are some tips for staying on stable versions:

• Pin your Docker image to a specific version tag (e.g., diegosouzapw/omniroute:v3.6.8) instead of :latest
• Create backups before each update via Dashboard -> Settings -> Backup
• Watch the CHANGELOG.md for breaking changes before updating

We will keep this discussion open for community input. Anyone else who wants a stable channel, please upvote this discussion!

[rdself]

Thanks for the thoughtful reply, @diegosouzapw.

I agree that pinning a specific version can reduce churn, but I do not think fixed version pinning is a complete solution. Many users still want bug fixes and model catalog updates from the current line; what they mainly want to avoid is regressions introduced by brand-new features.

So I am very glad to hear that a stable channel is already planned. My only suggestion is that it should probably not be limited to releases alone. The approach that seems most appropriate to me would be to maintain a separate stable branch alongside main, and then promote changes into it on different cadences:

• bug fixes and model list updates after sufficient validation, perhaps weekly
• larger new features only after repeated validation, perhaps monthly or even quarterly

This would definitely increase maintenance overhead, but I think AI-assisted cherry-picks and merges can make that much more manageable, and I would be happy to help if that direction makes sense.

Curious what others think.

[diegosouzapw]

Hi @rdself

Great news -- this has been implemented!

OmniRoute now uses a dual-track versioning strategy:

• v3.x (current): LTS/stability track -- bugfixes and security patches only
• • v4.x (upcoming): Feature track with Release Candidate (RC) cycles for testing new features before stable release
    This means you can stay on v3.x for a stable, production-safe experience, or opt into v4.x RCs when you want to test new features.

Thank you for proposing this -- it directly influenced our versioning strategy! Closing this discussion as implemented.