k8s API v1.21 and cdk8s-plus-21 about cdk8s-plus-17 HOT 10 CLOSED

@civilizeddev They will be versioned the same as all cdk8s module, but yes features could be added to each of the independently.

You're concern around duplication is valid, and we are actually discussing mechanisms on how to reuse them, so that features added to cdk8s-plus-19 will automatically be available in cdk8s-plus-20. If you are interested in starting up an additional cdk8s-plus library, let us know before you start because there are definitely some things to consider.

from cdk8s-plus-17.

@civilizeddev Sounds great. Let me think what our next steps her would be 👍

from cdk8s-plus-17.

@civilizeddev The cdk8s-plus-17 package contains high level API's for features and resources that exist in version 1.17.0. Note however that it can be deployed to clusters with version 1.17.0 or higher.

If you are looking for high level API's for features and resources that exist in version > 1.17.0 only, then this currently doesn't exist. For that we (or anyone who is interested) would need to create a new library cdk8s-plus-19 and add those features there.

However, you can use the low level L1 API of any spec version. Simply import the one you need:

cdk8s import [email protected]

Did that clear things up?

from cdk8s-plus-17.

@iliapolo
Thank you for the answer.

It's the last question.

If there were cdk8s-plus-19, cdk8s-plus-20 and cdk8s-plus-21, would they grow separately then?

I'm worried that it will lead a lot of duplicates among them. (partially different but almost the same)

from cdk8s-plus-17.

@civilizeddev The reason we did it this way is to be as type safe as possible, and not expose properties that might not exist in specific specs.

from cdk8s-plus-17.

@iliapolo

I am very interested in maintaining cdk8s-plus-20 because my team is currently using k8s v1.20.

I'd appreciate it if you could give me a chance to do it.

Please consider it.

from cdk8s-plus-17.

Based on decision described here - we need to come up with a fork-merge strategy to manually push necessary changes to each of the library version lines.

from cdk8s-plus-17.

As a first step, we decided we are going to create a single cdk8s-plus repository and have multiple release branches.

Each branch will correspond to a different k8s spec version.

So we will have, for example:

• k8s.21
• k8s.20
• k8s.19

The library name will be derived from the branch name, and versions are completely independent between those libraries.
This requires some projen hackery to support a different package name per release branch.

@Chriscbr

from cdk8s-plus-17.

Related: projen/projen#1079

from cdk8s-plus-17.

@Chriscbr We should also make sure to include an section in the README about our vending strategy:

• What do the version suffixes mean?
• Why are there so many?
• I operate Kubernetes version X - which package should I be using?
• Support model (3 latest k8s versions)

from cdk8s-plus-17.