-
Notifications
You must be signed in to change notification settings - Fork 14.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve patch releases page #46368
Improve patch releases page #46368
Conversation
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
data/i18n/en/en.toml
Outdated
@@ -519,12 +519,27 @@ other = "2006-01-02" | |||
[release_date_format_month] | |||
other = "January 2006" | |||
|
|||
# Use 2006-01-02 (ISO 8601) if you are not sure what to use. | |||
[release_date_format_text] | |||
other = "Monday, 02 Jan 2006" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this will work for localization teams.
This encoding is Golang specific, and the convention here won't translate well into any other languages.
ISO 8601 is a standard that can be followed by all localization teams though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
# Use 2006-01-02 (ISO 8601) if you are not sure what to use.
I could change that to explicitly mention that Hugo doesn't support localized date formatting. For English, we can still provide the tooltip, and if Hugo gains support, this will Just Work for other locales.
How about that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like we can localize dates, but we have to use the exact language codes.
https://discourse.gohugo.io/t/localizing-date-format/37868 has more on this.
<td> | ||
{{ time.Format ( T "release_date_format") $patchReleaseInfo.targetDate }} | ||
{{- with $patchReleaseInfo.targetDate -}} | ||
<time title="{{ time.Format ( T "release_date_format_text") . }}" datetime={{ time.Format "2006-01-02" . }}>{{ time.Format ( T "release_date_format" ) . }}</time> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm concerned with the direction of this change is leading us to.
There is no doubt that the automated generation of certain pages or elements could help improve productivity. But this is still a documentation project anyway. Over engineering may not be a good thing to website maintainers. Whenever possible, we should try "keep it simple and stupid (aka KISS)". Carving on shit is not something we as a community should encourage.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- The patch releases page is one of our most frequently updated pages and largely changes through data-driven changes.
- Rather than improve productivity for SIG Release, my intent here is to improve UX for people reading the rendered page.
For example, if you can see that an EOL date is a date your business does not usually work, that helps you plan.
It's even better for firms not to wait until the last possible moment to make a change, but I know there are corporations that wait exactly that long.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggested an alternative, more complicated approach: #46426
241ec56
to
b58fe0b
Compare
b58fe0b
to
3b5e7f8
Compare
3b5e7f8
to
8d7cdc7
Compare
8d7cdc7
to
6b228d7
Compare
I think this is ready for review. Please take a look, folks. |
6b228d7
to
f3f8adc
Compare
data/releases/eol.yaml
Outdated
- endOfLifeDate: "2021-05-12" | ||
finalPatchRelease: 1.18.19 | ||
note: '[Regression](https://groups.google.com/g/kubernetes-dev/c/KuF8s2zueFs)' | ||
note: >- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand this change, can you please clarify it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm also getting this diff when running schedule-builder:
diff --git a/data/releases/eol.yaml b/data/releases/eol.yaml
index 739b542b3f..e28b84f20a 100644
--- a/data/releases/eol.yaml
+++ b/data/releases/eol.yaml
@@ -48,9 +48,7 @@ branches:
release: "1.19"
- endOfLifeDate: "2021-06-18"
finalPatchRelease: 1.18.20
- note: >-
- Release 1.18.20 was created to solve a
- [regression](https://groups.google.com/g/kubernetes-dev/c/KuF8s2zueFs)
+ note: Release 1.18.20 was created to solve a [regression](https://groups.google.com/g/kubernetes-dev/c/KuF8s2zueFs)
introduced in 1.18.19
release: "1.18"
- endOfLifeDate: "2021-01-13"
-
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My intention making changes to this file was to fix some issues about how well the data fitted what the website needs - see 633460f
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops; when I started this PR, the file didn't have the helpful comment about being autogenerated.
Can we still fix v1.18 having two EOL dates?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, fixing that is fine, I also left a comment about fixing it for the v1.22 release.
@asem-hamid would you be willing to disclose the URL or URL path for the page that you think isn't right?
I assume that this is the patch releases page for Bangla? If so, it's not a regression; https://kubernetes.io/bn/releases/patch-releases/ is already buggy. See #48057 |
f3f8adc
to
20e9d32
Compare
- endOfLifeDate: "2021-05-12" | ||
finalPatchRelease: 1.18.19 | ||
note: '[Regression](https://groups.google.com/g/kubernetes-dev/c/KuF8s2zueFs)' | ||
release: "1.18" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed because having two v1.18 EOL dates is unhelpful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sftim To make it consistent, can you please do the same for the v1.22 release?
@@ -50,10 +50,6 @@ branches: | |||
finalPatchRelease: 1.18.20 | |||
note: Created to solve regression introduced in 1.18.19 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aside: this is not a note about v1.18; there's some challenge here about how we explain the available notes to readers.
Another PR can fix that, I hope.
75b45a7
to
26f69d7
Compare
data/i18n/en/en.toml
Outdated
# Used if the maintenance mode date is in the past, otherwise | ||
# see release_maintenance_and_end_of_life_details_current | ||
[release_maintenance_and_end_of_life_details_past] | ||
other = """🛈 **Kubernetes {{ .minor_version }} entered maintenance mode on {{ .maintenance_mode_start_date }}**. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, that's similar to ℹ️
I can switch it to something more widely supported.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would be great, other than that, the PR looks good to me!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(done)
@sftim Is it possible to make all tables wider, potentially taking all the available width? For example, we have such a table in the CVE feed. Ideally, that space would be used for the notes. |
Maybe, but that's best left for another PR. |
If we want a better list of minor / patch releases, see #46426 We'd end up with a page per [something]. Eg a page (and URL) per minor release, and a table that links to sections within the right minor release page. |
We had two EOL dates for v1.18, and three for v1.22, which was likely to confuse readers more than it helps them. Fix that.
and link to CVE list
26f69d7
to
fb19c41
Compare
- Use Hugo's built-in support for localizing dates - Allow customizing date formats separately - Make more dates machine readable - Add a tooltip for dates
fb19c41
to
3ab2d3a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for this PR, @sftim!
/lgtm
/approve
LGTM label has been added. Git tree hash: af8e0665e923d328ecbb11c3e406eaaff9f166dc
|
Given this has an approval from a SIG Release approver, then even though it is a change to the live site: |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sftim, xmudrii The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Improve https://kubernetes.io/releases/patch-releases/ especially around date rendering.