Fix support dates

[thatcode]

365 days and 90 days are not quite the same.

What type of PR is this?
/kind bug

What this PR does / why we need it:
This file references the support timelines as detailed in https://kubernetes-csi.github.io/docs/project-policies.html#support. This says:

The Kubernetes CSI project follows the broader Kubernetes project on support. Every minor release branch will be supported with patch releases on an as-needed basis for at least 1 year, starting with the first release of that minor version. In addition, the minor release branch will be supported for at least 3 months after the next minor version is released, to allow time to integrate with the latest release.

The code in this file uses 365 days as 1 year, and 90 days as 3 months, which is close but not quite the same. Using relativedelta enables us to get the dates exactly correct, even on leap years and more often for the 3 month cases.

This is quite minor (and probably a bit nit-picking!) but I also know of some automated checkers that don't like having references to 1 year and 365 days on the same line - as they're not the same! I'm having to patch this locally due to this, but thought I'd contribute it back upstream as it's easy.

Key decisions made that should be considered during review:

• I'm using dates, not datetimes. The support of a release probably shouldn't depend on the time of day?
• If a release was released a day ago, it's still supported. i.e., a first release of 28th April 2024 will be supported on 28th April 2025, but not on 29th April 2025.

Which issue(s) this PR fixes:

No current issues are fixed by this PR. Would it help if I raised one? I thought not at this point.

Special notes for your reviewer:
I have tested this with no changes in supported releases. Testing this file is rather specific to the current date! I have used faketime to test this on a variety of dates.

csi-driver-nfs fix-support-dates$ python3 ./release-tools/contrib/get_supported_version_csi-sidecar.py -R kubernetes-csi/external-health-monitor
Supported versions with release date and age of `kubernetes-csi/external-health-monitor`:

v0.14.0 2024-12-20      4 months ago
v0.13.0 2024-08-28      8 months ago
v0.12.1 2024-06-04      10 months ago

csi-driver-nfs fix-support-dates$ faketime "2025-05-24" python3 ./release-tools/contrib/get_supported_version_csi-sidecar.py -R kubernetes-csi/external-health-monitor
Supported versions with release date and age of `kubernetes-csi/external-health-monitor`:

v0.14.0 2024-12-20      5 months ago
v0.13.0 2024-08-28      8 months ago
v0.12.1 2024-06-04      11 months ago

csi-driver-nfs fix-support-dates$ faketime "2025-05-25" python3 ./release-tools/contrib/get_supported_version_csi-sidecar.py -R kubernetes-csi/external-health-monitor
Supported versions with release date and age of `kubernetes-csi/external-health-monitor`:

v0.14.0 2024-12-20      5 months ago
v0.13.0 2024-08-28      8 months ago

v0.12.1 drops support on 2025-05-25 because v0.12.0 was released on 2024-05-24, so 2025-05-24 is the last supported day.

Does this PR introduce a user-facing change?:

none

[linux-foundation-easycla]

• ✅login: thatcode / (43250f0)
• ✅login: thatcode / (43250f0, ed31e8e)

The committers listed above are authorized under a signed CLA.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: thatcode
Once this PR has been reviewed and has the lgtm label, please assign xing-yang for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• release-tools/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

Welcome @thatcode!

It looks like this is your first PR to kubernetes-csi/csi-driver-nfs 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-csi/csi-driver-nfs has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @thatcode. Thanks for your PR.

I'm waiting for a kubernetes-csi member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[coveralls]

Pull Request Test Coverage Report for Build 14759356772

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 78.178%

---

Totals
Change from base Build 14666256795:	0.0%
Covered Lines:	1107
Relevant Lines:	1416

---

💛 - Coveralls

[andyzhangx]

can you make the change in https://github.com/kubernetes-csi/csi-release-tools/blob/master/contrib/get_supported_version_csi-sidecar.py? thanks.

[thatcode]

I did wonder why this file was mastered here! Thanks for pointing me to the canonical location - I'll do as you suggest.

Once/if I get this changed there, what's the process for changing it here? Is it automatic? Or would this PR still have use for that? I'm probably happy to close this PR and then re-open if it's useful later? What do you suggest?

Edit: Now done, in kubernetes-csi/csi-release-tools#276.

[andyzhangx]

I did wonder why this file was mastered here! Thanks for pointing me to the canonical location - I'll do as you suggest.

Once/if I get this changed there, what's the process for changing it here? Is it automatic? Or would this PR still have use for that? I'm probably happy to close this PR and then re-open if it's useful later? What do you suggest?

Edit: Now done, in kubernetes-csi/csi-release-tools#276.

after the PR in csi-release-tools is merged, you could run following command to update the csi-release-tools in this repo:

git subtree pull --squash --prefix=release-tools https://github.com/kubernetes-csi/csi-release-tools.git master