Comment 1 for bug 1684529

While snapcraft provides the --release flag as a convenience, in reality the process happens in distinct stages:

- First the snap is pushed to the store
- Once pushed, it undergoes review. Snapcraft waits to hear from the store on the result.
- If the store says the snap is ready to publish (passed automated review) then snapcraft issues a publish API request to the specified channel.

But note that if the store says the snap is NOT ready to publish (held for manual review, held behind another upload pending review or outright failed automated review) then snapcraft exits and doesn't have a chance to issue the publish request. Like you observed, an explicit snapcraft release is required in order to publish at this point.

Keeping these steps separated store-side makes sense since, for instance, there's no guarantee about how long the snap will take to complete its review. If, hypothetically, the snap were pushed with some bit saying "publish to stable when it's reviewed", and it gets held for review, it could end up being published hours or days after being uploaded, a behavior which could be surprising for developers or users.

Also, we've seen cases of developers changing their snaps in response to automated review error messages, this suggests sometimes the automated review did catch problems which the developer prefers not having published. If a reviewer happens to miss one of those errors, approves the snap and it gets auto-published from under the developer, an undesirable snap may end up being published. Halting the publishing process in the face of automated review failure makes sense in this context.

To be clear, the behavior you describe can be implemented, though it will require design and implementation with some consideration of the above and other possible scenarios.