New Release Needed.

[Venkatesh-j-koppar]

Hi maintainers,

Thank you for your work on this project!

I’m wondering if there’s a release planned in the coming days that would include PR #2514. I’ve been waiting for this fix and would really appreciate if it could be part of the next tagged version — even a patch release would be great.

Thanks again.

[cjihrig]

+1 to cutting a new release, it's been a couple months. I can do one early next week if no one beats me to it. I don't really want to cut a new release on a Friday in case it creates unexpected work for myself or others.

[brendandburns]

We will do a new 1.4.x release when the new Kubernetes version (1.34.x) releases (estimated 8/25/25).

Alternately, if you send a couple PRs to the release-1.3 branch:

• cherry-pick the commits from FIX: Adding support for multiple client #2514 into the release-1.3 branch
• update the package.json and package-lock.json to be version 1.3.1

We could do a patch release, which might be slightly faster than waiting for the k8s release.

[brendandburns]

@cjihrig

fwiw I think we need to discuss our versioning policy. In the Java client we chose to increase the major version whenever we move to a new Kubernetes release. In this library we have sort-of used the minor version for a new API, but we've also rev'd the minor version when we've made significant client changes.

I propose that we do the following:

• Major version increment aligned with k8s version increment (but not the version #) so after 1.34 releases, we would rev to 2.0.0 instead of 1.4.0
• Minor versions used for standard periodic updates from main (we should maybe automate this?)
• Patch versions (used sparingly for cherry-picks of security and bug fixes into older versions of the client, standard 3 version support window)

Thoughts?

[cjihrig]

I'm not opposed to that proposal. The only thing I'd point out is that most of the JavaScript ecosystem has settled on SemVer for versioning. Using a different versioning scheme could lead to confusion for users.

[brendandburns]

My intent was that we should follow semvar as well, I'm going to rephrase to be precise:

• Major version increments aligned with k8s version increment. K8S version changes are breaking API changes, we will release from main when we perform this release, every ~3-4 months.
• Minor version increments when there are significant changes in main that someone wants in the current active version via cherry-pick into the currently released branch release-X eg. release-2 these cherry picks are only applied to the latest live major version, not into previous versions.
• Patch versions (used sparingly for cherry-picks of security and bug fixes into older versions of the client, standard 3 version support window)

The motivation for aligning k8s version to major version is that it makes the compatability table much clearer and easier for people to understand and new k8s is definitely a new major version according to SemVar rules.

Thoughts?

[mstruebing]

I like that idea as it's easier to follow.
One question I would have is how we'd do some major rewrite like we've did with request -> node-fetch (and possibly fetch soonish(?), even though that should be way less troublesome).

If we would increment major the version we wouldn't be able to support two different branches for a longer period of time, basically until the next k8s release. Increment the minor isn't really appropriate for that either, but there might be ways with suffixes i.e. 1.0.0-fetch/1.0.0-request.
Anyway, that may not even a problem we will face soonish, but a question that came to my mind.

[cjihrig]

I'm good with following semver, and I agree that aligning K8s releases with majors simplifies things.

One question I would have is how we'd do some major rewrite like we've did with request -> node-fetch

I imagine in that case, the major rewrite would have to be synchronized with a major release. I picture this working similarly to how Node itself handles releases. There is a main branch where every change immediately lands. Then, there are release lines (v20, v22, v23, v24, etc.) that commits are appropriately cherry-picked to. The biggest challenge I see with that approach is that it sometimes requires a fair amount of manual work (which this project does not have a ton of) to do the cherry-picking and managing conflicts (which is why Node is currently looking to simplify their release cycle a bit).

[brendandburns]

wrt to the cost of back-ports, I think that we will benefit from the fact that the k8s release cycle is ~3-4 months, so at the worst someone has to wait 3-4 months to get a release with the change in main. That will probably reduce the incentive to back-port complicated fixes.

[Tanmayshi]

Hi,

Regarding the PR(#2548 )I resolved where the dependency was changed from js-yaml to yaml, I wanted to ask if this change will be included in the next major release since it’s a significant dependency update.

Also, I feel it would be good to have a discussion on whether to continue with js-yaml or fully switch to yaml, as this can impact compatibility and maintenance.