Tracking remaining but notable issues in v1alpha2 release

[resouer]

Though still under pre-release, OAM v1alpha2 has been adopted rapidly among significant community platform builders recently. Based on the feedbacks, I'd suggest we consider the remaining issues as a whole picture of a production level application model.

• [P0] Components dependency - the best answer to "why OAM": Resource Dependency in OAM #326
  • [P2] Application for developers to grouping components: How can a developer represent the application prior to application configuration? #334 - this one can also be used to solve Resource Dependency in OAM #326 if we want to add a "application" concept in implementation first.
• [P0] Mutable components - the best answer to "why v1alpha2": The Component should mutable #350
• [P1] Policy system - the best answer to "why not DevOps": What if Developer has opinion to Traits? #153

The principle is we only want to have minimal impact on v1alpha2 release, thus I highly recommend we follow "promotion based API change" approach which has been practiced in Kubernetes community for years, i.e. use outbound objects and unstructured annotations instead of direct API change for alpha stage features and then promote it to API fields in beta.

So I'd assume the first version of above change swill happen on implementation side by annotations, and then we promote the API change to OAM spec according to users' feedback in further releases.

[resouer]

Clarify: #334 is better to be introduced to OAM spec instead of implementation. The reason I listed here is it can be used to solve #326 (component dependency) if we decide to move #334 forward in impl side firstly. Otherwise, we can defer it and focus on #326 .

I've updated the issue to reflect this idea. /cc @artursouza

[resouer]

[Update] According feedback from community as well as maintainers. It seems we are more inclined to change the OAM spec instead of annotations or temporary objects to ship above features in oam-kubernetes-runtime. See: crossplane/oam-kubernetes-runtime#24 (review) crossplane/oam-kubernetes-runtime#29 (comment).

It's very reasonable. So we will create new fields or API objects in implementation side directly and reflect them in the spec doc as EXPERIMENTAL . Though in order to keep the spec versioned and maintainable, we will add a mechanism to enable API spec promotion. Will raise this discussion as follow up issue.