autoPromotion by Semantic Version

[christianhuth]

Checklist

• I've searched the issue queue to verify this is not a duplicate feature request.

Proposed Feature

At the moment we can define on Project level if we want to enable auto promotion using the autoPromotionEnabled attribute.

I think an option like autoPromotionForMinorVersion, autoPromotionForPatchVersion, autoPromoationBySemVer or similar would be a great addition. Setting this attribute to true will only auto promote a freight to a stage if there is a change in the Minor or Patch version level.

Motivation

AutoPromotion of Breaking Changes (= Major version change according to SemanticVersion) can break an application.

[krancour]

This is not an outright "no," but I think there are three specific considerations to weigh:

1. I'm inferring that the proposal deals with the narrow use case of a single image reference in a piece of Freight. Keeping in mind that a piece of Freight is a collection of artifact references, it's not clear how this generalizes to Freight referencing n artifacts, some of which may not even be semantically versioned.

2. Semantic version constraints are already possible on a per-subscription basis in Warehouses. With this existing capability of admitting only versions in an acceptable range into the system to begin with, what is the added benefit of the proposed policies?

3. Promotion policies are defined at the Project-level for security reasons. Assume that there might be a few developers on a team that have sufficient permission to edit Stages, but lack permissions to promote. If the switch for enabling auto-promoting were at the Stage-level, it would be possible for someone not authorized to promote to make a promotion happen anyway just by switching on auto-promotion. This is why that switch is at the Project-level, were, presumably, someone with greater permissions has the final say on auto-promotions. This is a long way of saying: The existing policy is where it is for security reasons, but doesn't feel like the right place to be defining behavioral things such as version constraints.

Happy to discuss further if you want to tweak the proposal a bit.