Semantic versioning constraints for components

[kajogo777]

Use case

A service invoices depends on another service's stack users, and we to make sure that a supported version of users is deployed when building a local dev stack.

Proposal

Schema

#SemVer: {
    prefix: string | *""
    major:  uint | *0
    minor:  uint | *0
    patch:  uint | *0
    suffix: string | *""
    value:  "\(prefix)\(major).\(minor).\(patch)\(suffix)"
}

#Component: {
    $metadata: {
        id: string
        labels: [string]: string
        version: #SemVer
    }
    #Trait
}

Service invoices that depends on an imported stack of another service users and want to constrain the supported version

package main

import (
    "guku.io/devx/v1"
    "guku.io/devx/v1/traits"
)

stack: v1.#Stack & {
    components: {
        users: $metadata: version: {
            major: 10
            minor: >=20
        }
        invoices: {
            traits.#Workload
            containers: default: {
                image: "docker/whalesay"
                command: ["cowsay"]
                args: ["Hello DevX!"]
                env: USER_SERVICE_HOST: users.endpoints.default.host
            }
        }
    }
}

[kajogo777]

should this be managed by the package manager instead?

[AntPAllen]

Hi, been spending the last couple of days looking through this project, and massive kudos. I'd been building something extremely similar internally, even down to the naming and versioning scheme of definitions. I'm guessing you too took inspiration from OAM/KubeVela but also decided that just generating manifests/config was a simpler, more managable technique? Anyway, this use case in this issue is exactly what I'm trying to do at the moment, and my opinion is that this should be left to the package manager. Also curious as to how you are thinking of implementing this concretely? I'm currently thinking of defining a StackDependency trait to prevent dependent stacks being built outside of local dev. Another use case for this is for generating relations in backstage catalog-info.yaml (https://backstage.io/docs/features/software-catalog/descriptor-format#common-to-all-kinds-relations) and defining dependencies when generating terraform for pagerduty: https://support.pagerduty.com/docs/service-graph#create-service-dependencies