search

crossplane / addon-oam-kubernetes-local

Run OAM workloads on a Kubernetes cluster.
Apache License 2.0
21 stars 15 forks source link

revamp core controllers to use oam-kubernetes-runtime and refactor directory #26

Closed ryanzhang-oss closed 4 years ago

ryanzhang-oss commented 4 years ago

revamp core controllers to use oam-kubernetes-runtime and refactor directory

hongchaodeng commented 4 years ago

please resolve conflicts

hongchaodeng commented 4 years ago

lgtm

negz commented 4 years ago

@ryanzhang-oss I haven't had a chance to review this yet since we're heads down preparing for the Crossplane 0.11 release, which is planned for Tuesday morning PST. Is this PR addressing only cleanup, i.e. with no API or behaviour changes?

I'm wondering whether we intend to get this reviewed and merged in time to release it alongside Crossplane 0.11. Would it be safer for us to cut a release without these changes, since we've been able to run the current code in demos to build confidence?

ryanzhang-oss commented 4 years ago

I'm wondering whether we intend to get this reviewed and merged in time to release it alongside Crossplane 0.11. Would it be safer for us to cut a release without these changes since we've been able to run the current code in demos to build confidence?

This implements https://github.com/crossplane/crossplane/pull/1454 so it will affect the behavior. I don't think this should be cut into Crossplane 0.11. However, I do not think we should hold PRs based on the release cadence. There are several ways to manage a release that I have practiced in my previous production environments but none holds back a PR.
There are mainly two options. We can either

Either way, I don't think a release should slow down the code velocity.
Furthermore, I think we should break down the crossplane org into several modules so that each can have its own release schedule. For example, we should have a Crossplane application model release and a Crossplane resource model release.

hongchaodeng commented 4 years ago

Let's cut a release and then merge this PR into master?

resouer commented 4 years ago

Agree with @ryanzhang-oss, as Crossplane is rapidly evolving to an open and community driven project, we need to consider a release model without hurting the contribution velocity.

Since we are now very close to community day, we can continue on dev branch. While in the future, it seems more reasonable to cut release branch.

And it does make sense to allow Crossplane application model (oam-runtime + core controllers) have separate release. That would be easier to keep the stability for Crossplane as a whole.

hongchaodeng commented 4 years ago

lgtm