[azure-kubernetes] Fix LTS dates

[jacobtomlinson]

In #6123 an LTS date for Azure Kubernetes 1.30 was added. The fields used are inconsistent with the existing LTS dates for 1.27.

In 1.27 the eol field was used for the LTS EOL date, and the lts field was used for the original non-LTS eol date. In 1.30 these fields have been switched. The 1.27 data also has an eoas field with the same value as lts which gets rendered as a field called support which does not exist for 1.30.

It makes more sense to me to use the eol field for the original non-LTS EOL date, and the lts field for the extended LTS EOL date. So this PR updates the 1.27 data to be consistent with the 1.30 data.

[welcome]

Thank you for opening this pull request 👍. If you are not familiar with the project, please check out our Contributing Guidelines and our Guiding Principles. Also take a look at our Hacking Guide if you intend to work on site internals.

[jacobtomlinson]

cc @MathieuPuech @chenrui333 as author and reviewer of #6123

[usta]

Could you make at least the releaseDate(1.30) and EOL|LTS(1.7) same ?

[captn3m0]

Just for clarity:

lts is meant to hold the LTS status for a release (bool). In case an exact LTS start date is available (since many products promote a release to LTS after some time), we use the lts parameter as a date. This is the relevant explanation from https://endoflife.date/contribute:

# Whether this is a "LTS" release (optional, default = false).
# What LTS means may differ from product to product (see LTSLabel above).
# Only provide for a release that will get much longer support than usual.
# Alternatively, this can be set to a date when the product is not labeled
# as LTS when it is released (ex. Angular) or when normal versions are
# promoted LTS after their release (ex. Jenkins).

As such:

• lts should be set to the midway mark for LTS release (releaseDate+1y)
• eol should be set to releaseDate + 1y for non-LTS releases, and releaseDate + 2y for LTS releases.