Proposal: Support multiple-revisions of functions

Support multiple-revisions of functions

Description

We should consider how to enable / support multiple-revisions of OpenFaaS functions. This is currently done by changing the name of the function before deployment.

If possible we could use a new feature-flag (for backwards compatibility) and conventions on the Docker image tag to support multiple concurrent versions of functions.

Imagine three different git commits and image tags defined in your stack.yml file:

functions:
  # version allows multiple slash commands in one comment
  name: derek
  image: derek:ef5ja
 
functions:
  # version has rebase command enabled
  name: derek
  image: derek:ffa3j

functions:  
  # version represents latest stable release, indicated via sem-ver
  name: derek
  image: derek:0.6.0 

This would produce 3 endpoints when deployed:

/function/derek-dev
/function/derek-ffa3j
/function/derek-0.6.0

We may want to then add an additional route like /release or /revision which can make use of "smart" aliases:

/release/derek/dev/    latest SHA   (ef5ja)
/release/derek/ffa3j/  other  SHA   (ffa3j)
/release/derek/0.6.0/  specific semver
/release/derek/0.6.1/   specific semver
/release/derek/  latest semver (0.6.1)

When we have two semver versions we can order these using a semver sort so that /release/derek/ points to 0.6.1.

Ideas for feature: Alex / Stefan

Start by reviewing how functions in stack.yml are deployed from their Docker image tags and how the existing /function endpoints are routed. Define the scope for a feature flag, concurrent revision endpoints, and the proposed /release aliases, then confirm the expected behavior for SHA and semver versions.