I’d like to open a discussion regarding the Build Promotion feature in ProGet.

Currently, as far as I can see, ProGet allows users to promote a build from any stage to any stage. While this offers a lot of flexibility, it also introduces a significant risk: the ability to promote a build "backward" (i.e., downgrading or promoting to a lower stage/previous environment).

The Problem

In many workflows, build promotion should strictly be a one-way street (forward-only). If a team needs to reproduce a production bug, they might want to deploy/promote a specific older build to a non-production environment (like Staging or QA). However, because the tool allows promotion from any stage to any stage, there is a high risk of accidentally performing an unwanted promotion (such as pushing an older/wrong version into a higher pipeline stage by mistake, or mixing up the promotion flow).

Allowing backward promotion bypasses the logical progression of a standard release pipeline (e.g., Build ➔ Integration ➔ QA ➔ Production).

Proposed Evolution

I believe ProGet should offer an option (or a default behavior) to restrict build promotions to forward-only. Once a build reaches a certain stage, it should not be allowed to be promoted "backward" to a prior stage in the pipeline.

️ Crucially, this restriction should apply to both the Web UI and the API to ensure that automated scripts or manual actions cannot bypass this safety guardrail.

This would:

1. Prevent accidental misconfigurations or human errors during hotfixes and debugging phases.
2. Ensure strict adherence to the defined pipeline lifecycle.

What are your thoughts on this? How do you currently handle this risk in your pipelines, and would you find such a restriction useful in ProGet?

Looking forward to your feedback!