Fix support dates for CSI sidecars

[thatcode]

• Supported releases should probably be done by day, rather than changing on the time of day.
• Use 1 year and 3 months as stated in https://kubernetes-csi.github.io/docs/project-policies.html#support, rather than 365 days and 90 days, which 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 on this day a year 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-release-tools fix-support-dates$ python3 ./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-release-tools fix-support-dates$ faketime "2025-05-24" python3 ./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-release-tools fix-support-dates$ faketime "2025-05-25" python3 ./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

[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 jsafrane 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:

• 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-release-tools 🎉. 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-release-tools 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.

[andyzhangx]

/ok-to-test

[thatcode]

I'm really sorry if I've misread the guidelines, but step 1 of the guidance says:
Make sure that your pull request has an assigned reviewer (assignee in GitHub). If not, reply to the pull request comment stream asking for a reviewer to be assigned. This is done via a bot command (the bot may have suggestions for this) and looks like this: /assign @username.

It feels a bit presumptuous to assign a reviewer, but I think that's what it's telling me to do... Sorry if I am incorrect.

/assign @gnufied

[thatcode]

As per step 2 of the guidance:

@gnufied Is it possible to have an ETA on a review of this PR? Or some feedback on this change?

Thanks!
Robert

[thatcode]

Trying next reviewer.

Can I please have feedback on this PR, or an estimate of when that might be possible? I have seen this post on the K8s Slack so understand it might not be a good time for this PR, but it'd be good to know this is why the review is being delayed, rather than the silence I'm currently getting!

Thanks :)

/assign @pohly

[thatcode]

@pohly @gnufied How can I best make progress here? I've been through the guidance, and I'm not sure how else to get review without being annoying, which I don't want to do...