The v0.3.0 release of OAM specification

This marks the v0.3.0 release of OAM spec.

Since the last release, the spec has undergone the following major changes and improvements:

• The Application entity has been updated that its components now exposes simplified config attributes to users.
  Behind the scene, the ComponentDefition will be defined by platform team with the actual templating definition.
  In this way, it provides better separation of concerns -- it simplifies the user interfafce, and let the platform experts focus on handling the infra details.

  Here is an example:

  apiVersion: core.oam.dev/v1beta1
  kind: Application
  metadata:
    name: my-example-app
    annotations:
      version: v1.0.0
      description: "Brief description of the application"
  spec:
    components:
      - name: publicweb
        type: web-ui
        properties: # properties targeting component parameters.
          image: example/web-ui:v1.0.2@sha256:verytrustworthyhash
          param_1: "enabled" # param_1 is defined on the web-ui component
        traits:
          - type: ingress # ingress trait providing a public endpoint for the publicweb component of the application.
            properties: # properties are defined by the trait CRD spec. This example assumes path and port.
              path: /
              port: 8080
        scopes:
          "healthscopes.core.oam.dev": "app-health" # An application level health scope including both components.
      - name: backend
        type: company/test-backend # test-backend is referenced from other namespace
        properties:
          debug: "true" # debug is a parameter defined in the test-backend component.
        traits:
          - type: scaler # scaler trait to specify the number of replicas for the backend component
            properties:
              replicas: 4
        scopes:
          "healthscopes.core.oam.dev": "app-health" # An application level health scope including both components.

• The ComponentDefinition entity has been introduced to replace previous WorkloadDefinition.
  It provides CUE based schematic information which would describe the actual execution plan and
  expose parameters in infra-agnostic format.

  Here is an example:

  apiVersion: core.oam.dev/v1beta1
  kind: ComponentDefinition
  metadata:
    name: webserver
    annotations:
      definition.oam.dev/description: "webserver is a combo of Deployment + Service"
  spec:
    workload:
      definition:
        apiVersion: apps/v1
        kind: Deployment
    schematic:
      cue:
        template: |
          output: {
              apiVersion: "apps/v1"
              kind:       "Deployment"
              spec: {
                  selector: matchLabels: {
                      "app.oam.dev/component": context.name
                  }
                  template: {
                      metadata: labels: {
                          "app.oam.dev/component": context.name
                      }
                      spec: {
                          containers: [{
                              name:  context.name
                              image: parameter.image
  
                              if parameter["cmd"] != _|_ {
                                  command: parameter.cmd
                              }
                              ...
                          }]
                  }
                  }
              }
          }
          // an extra template
          outputs: service: {
              apiVersion: "v1"
              kind:       "Service"
              spec: {
                  selector: {
                      "app.oam.dev/component": context.name
                  }
                  ports: [
                      {
                          port:       parameter.port
                          targetPort: parameter.port
                      },
                  ]
              }
          }
          parameter: {
              image: string
              cmd?: [...string]
              port: *80 | int
          }

• Replace Workload to Component and WorkloadDefinition to ComponentDefinition to reflect latest changes.

• The design principles has been updated to highlight runtime neutrality and separation of concerns.
  This is more reflected in the latest Application and ComponentDefinition changes.

• Semantic versioning has been introduced with the latest release pointed to v0.3.0, and v0.1.x and v0.2.x put into previous releases

Want to give it a try? Check out tutorials of KubeVela. Feedback is welcome!

Thanks to the contributors in this release: @dhiguero @resouer @mayocream @rhew @wonderflow @hongchaodeng @chilung @dchjmichael @pmorie @rynowak @szihai @AnubhavSingh16

The v0.2.1 release of OAM specification

This marks the v0.2.1 release of OAM spec.

Since the v0.2.0 release, the spec has undergone following changes and improvements:

• Reflect Component mutability and revisioning in Spec #356
  • Implemented in OAM Kubernetes Runtime: crossplane/oam-kubernetes-runtime#35
• The versioning and release of the Spec is decoupled from APIVersion #369
• Update introduction and diagram to reflect changes from ComponentSchematic to Component #360
• Replace Rudr with Crossplane in README #359
• Clarifying OAM Spec adopts Kubernetes resource model #358
• JSON field paths do not require leading dot #347

Want to give it a try? Check out tutorials of oam-kubernetes-runtime. Feedback is welcome!

Thanks to the contributors in this release: @wonderflow @ryanzhang-oss @resouer @hongchaodeng @zzxwill @rootsongjc @AnubhavSingh16 @vturecek @negz @hasheddan

The v0.2.0 release of OAM specification

This marks the v0.2.0 release of OAM spec (previously named v1.0.0-alpha2 release).

Since the v0.1.0 release, the community keeps growing. We have welcome more contributors and made significant improvement based on user feedback:

• New contributors from Upbound and Huawei has joined the community 🚀
• A new proposal, Kubernetes Friendly OAM, has been accepted and lead to a major update on the spec. With this change, OAM can directly leverage the existing custom resources in the Kubernetes ecosystem. See: What's New in OAM v1alpha2
• Crossplane is adopting OAM since v0.2.0 spec and going to release v0.11 version based on it. To learn more please join #oam channel in Slack.

Interested in helping out? Jump right in! Read through the spec. Propose new features or help us spot inconsistencies. And perhaps most importantly, give it a try so we can solve more real-world problems!

Thanks to the contributors in this release: @wonderflow @ryanzhang-oss @hongchaodeng @negz @resouer @vturecek @artursouza @erikadoyle @s304981561 @nmackenzie @juniorz @juniorz @suhuruli @captainroy-hy @fatkun

The v0.1.0 release of OAM specification

This release is marks a completed draft of the Open Application Model (OAM) specification (previously named v1.0.0-alpha1 release). While the spec is still "unstable" and subject to breaking changes, we believe this is a good starting point for describing distributed applications in the cloud native ecosystem.

Interested in helping out? Jump right in! Read through the spec. Help us spot typos and inconsistencies. Propose new features. And perhaps most importantly, give it a try so we can learn whether the model is solving real-world problems!