You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With v2 release we are currently at the point, where most of the features we wanted to add are there. Except for the Dependent Resources: #726 for which there is a prototype.
Dependent resources is a higher level abstraction to manage resources in a more declarative way.
The dependent resources feature however would require more iterations, testing, documentation, samples, maybe even some case studies before it can be fully released. Also there are some questions if other then Kubernetes resources should be supported by it and how (like dependencies between resources).
The question is how to approach this from the perspective of our road map:
On one hand we would like to have a v2 release soon so the upcoming projects can use is instead of v1
on the other side we know that dependent resources will introduce some API changes for sure. Although those API changes won't be that significant like between v1 -> v2 (current state).
So there the following options:
Release v2 with the current scope without dependent resources, and conitinue to work on them targeting v2.1 (or v3). Note that other issues might come in close future like Reactive programming model support. The negative impact of this, that this would leave eventually to additional API changes, so migration from the users will be required again, but the migration path should be very simple.
Delay the release and implement dependent resource. With this we avoid new API changes (althoug Reactive will change it for sure) with the dependent resources. We will have feedback later for v2, and the release might be delayed significantly (weeks).
Try to prepare the API changes upfront where it makes sense. This is a compromise between 1. and 2. The risk here is that this is some guessing to some extent, some of the changes might not make sense with the current scope and might lead to harder understanding of the code. In addition to that, the APIs could again change after we develop dependent resources further.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
With v2 release we are currently at the point, where most of the features we wanted to add are there. Except for the Dependent Resources: #726 for which there is a prototype.
Dependent resources is a higher level abstraction to manage resources in a more declarative way.
The dependent resources feature however would require more iterations, testing, documentation, samples, maybe even some case studies before it can be fully released. Also there are some questions if other then Kubernetes resources should be supported by it and how (like dependencies between resources).
The question is how to approach this from the perspective of our road map:
So there the following options:
Release v2 with the current scope without dependent resources, and conitinue to work on them targeting v2.1 (or v3). Note that other issues might come in close future like Reactive programming model support. The negative impact of this, that this would leave eventually to additional API changes, so migration from the users will be required again, but the migration path should be very simple.
Delay the release and implement dependent resource. With this we avoid new API changes (althoug Reactive will change it for sure) with the dependent resources. We will have feedback later for v2, and the release might be delayed significantly (weeks).
Try to prepare the API changes upfront where it makes sense. This is a compromise between 1. and 2. The risk here is that this is some guessing to some extent, some of the changes might not make sense with the current scope and might lead to harder understanding of the code. In addition to that, the APIs could again change after we develop dependent resources further.
Beta Was this translation helpful? Give feedback.
All reactions