-
Notifications
You must be signed in to change notification settings - Fork 14.5k
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
Adding a release page under "Release Information" #27929
Conversation
Deploy preview for kubernetes-io-master-staging ready! Built with commit 7edf890 https://deploy-preview-27929--kubernetes-io-master-staging.netlify.app |
09600cf
to
aa2cad9
Compare
https://deploy-preview-27929--kubernetes-io-master-staging.netlify.app/releases/ looks much better than https://kubernetes.io/docs/setup/release/ I'll review more later. |
scripts/update-release-info.sh
Outdated
--- | ||
EOF | ||
|
||
curl https://raw.githubusercontent.com/kubernetes/sig-release/master/releases/patch-releases.md >> content/en/releases/patch-releases.md |
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.
Future work: split https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md into 2 pages, one for https://k8s.dev/ and one for https://k8s.io/docs/
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.
Quick review just highlighting some of the links that will need to be updated via the script.
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.
@jimangel this looks really really promising. I also have a bit more feedback.
@@ -233,3 +233,20 @@ aliases: | |||
- mrbobbytables | |||
- nikhita | |||
- parispittman | |||
# authoritative source: git.k8s.io/release/OWNERS_ALIASES | |||
release-engineering-approvers: | |||
- cpanato # Release Manager |
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.
@jimangel . I am reading through the changes.
My first reaction is that this is a largish list of approvers/reviewers to add to the docs repository.
Why is this needed/for what purpose?
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 appreciate the concern! Adding them to the OWNERS_ALIASES
doesn't give them the level of authority the name implies. We could change that, but I copied it as is from git.k8s.io/release/OWNERS_ALIASES
. The groups are used to reference approvers & reviewers in their respective release sub folders (via sub OWNERS
file).
The release data that is being used by SIG Docs is owned by SIG Release. We'd like to have them store date in our repo for generation purposes. In order to do that efficiently, it made sense to grant SIG Release folks access to their respective sub directories.
We could also demo this MVP with a smaller list to start if you'd be more comfortable! Let me know if that helps. It's also possible I messed up my understandings of OWNERS files 😅
|
||
<!-- overview --> | ||
|
||
The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}). Kubernetes 1.19 and newer receive approximately 1 year of patch support. Kubernetes 1.18 and older received approximately 9 months of patch support. |
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.
Is there another doc that lists or describes the Kubernetes patch support rules?
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 stole that overview from "https://kubernetes.io/docs/setup/release/version-skew-policy/" because I thought it was helpful (although recognized duplication). The version skew policy page has been relocated to this new menu and I've added redirects from the old location.
I'm open to any alternative suggestions for the main overview!
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.
At this point I think we can drop the bit about k8s 1.18 and older:
The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}). Kubernetes 1.19 and newer receive approximately 1 year of patch support. Kubernetes 1.18 and older received approximately 9 months of patch support. | |
The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}). Kubernetes 1.19 and newer receive approximately 1 year of patch support. |
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 it hurts to leave it in for a little longer. I could be sold either way. 🤷
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 agree. I would leave it in a little longer.
@@ -0,0 +1,188 @@ | |||
--- | |||
title: Patch Release Details | |||
type: docs |
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.
What is the type?
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.
This is somewhat of a "hack" to have Hugo look at /layouts/docs/ for it's templates. It allows me to use the same "Docs" 3-bar theme for a handful of release docs. It also reduces the need for me to create custom CSS.
aa2cad9
to
b2a77ec
Compare
Hi @jimangel . Some initial feedback: |
Thanks for the review @kbhawkey. I updated some of your comments inline and will answer the rest here.
Exactly. This PR adds a location for release content and grants SIG Release co-ownership.
The script could be ran as needed at first (by release team or docs team). The ultimate goal would be to allow SIG Releases tooling to open the PR to update the data file. While the data is important, I don't believe it needs to be 100% automated to get started -- yet.
I'm not sure what you're referencing here. Would you mind clarifying? As far as the current content, I would be ok with removing a lot of it if it improves the end user experience.
Totally agree! I REALLY wanted it to be a big header that said, "RELEASES" but when I set it up, it looked very strange next to "VERSIONS." I would imagine that would be hard to understand from a new user too. I don't love it where it is now (under the Versions menu) but it seems to make the most logical sense. I'm up for any additional placement / title! Any suggestions?
There's alternative ways to run scripts (via Hugo, Netlify, Makefiles / shell) to capture content from URL endpoints. The concern with that is the reliance of data connectivity and increasing the complexity of our build dependencies. I would be up for alternative suggestions but I do feel like there is a very limited scope of access being opened up to SIG Release. As always, thanks again for your review / attention to detail! |
b2a77ec
to
83559ca
Compare
11f9ccd
to
69311b1
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.
Generally I'm very supportive about this, glad to see it landing ❤️
Thanks @jimangel! 🙏
This is amazing work. Thank you for it +1 |
|
||
EOF | ||
|
||
curl --retry 3 https://raw.githubusercontent.com/kubernetes/sig-release/master/releases/patch-releases.md >> content/en/releases/patch-releases.md |
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.
Non-blocking: Worth noting that when branch names flip over to main
, this script will break
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.
@celestehorgan -- We'll obviate the need for this ahead of any branch renames.
3721222
to
7edf890
Compare
/unhold I just updated with everyone's actionable feedback. I left the open-ended questions posted for reference later. This is ready to I would like +1/2 from a few more @kubernetes/sig-docs-leads 🙏 ❤️ |
re-lgtm on behalf of SIG Release |
LGTM label has been added. Git tree hash: b72f57c9c8bde0485f2885f9786b9ed10730c547
|
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.
/lgtm
I am very supportive of this. This is outstanding work! Great job @jimangel!!! |
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.
/lgtm
Given #27929 (comment) and other LGTMs |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: justaugustus, saschagrunert, sftim 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 |
Issue #29711 requests enhancing this with release date information |
Fixes: #20293
Working with SIG Release and SIG Docs, I'm proposing a "MVP," or "Phase 1," of consolidating Kubernetes' release documentation. A wave of improvements could follow once this foundation exists.
The ultimate goal is to raise visibility into the Kubernetes release cycle and reduce website information fragmentation. (More history in original issue: #20293)
Given the countless ways to consume and visualize release data, this PR focuses on a few high-level goals:
*dual sourced as in created and maintained in two locations.
If folks agree with this approach, I recommend merging this PR, after initial review, and we can iterate on feedback after? 👍 👎
General Architecture
[k/sig-release]
--copy-->[k/website/data]
--generate-->[k/website/releases]
A folder created in
content/en/releases
creates a new k8s.io/releases page.A script
./scripts/update-release-info.sh
copies release markdown pages from SIG Release.Data for Kubernetes versions is copied from SIG Release and stored in
data/releases/schedule.yaml
All content copied over has a modified front matter of
type: docs
prepended in order to inherit the main "/docs" theme for consistency.A new shortcode
{{< release-data >}}
was created to render release information fromdata/releases/schedule.yaml
inlayouts/shortcodes/release-data.html
. This section could be broken into a couplepartials
or multiple shortcodes. However, I found keeping everything in a single file made it easier to connect all the parts.content/en/releases/_index.html
builds the entire section and pulls the latest html-ready release data using the shortcode{{< release-data >}}
An OWNERS file is placed in
data/releases/
,content/en/releases/
that includes SIG Release.Summed up:
content/en/releases/
)data/releases/schedule.yaml
)content/en/releases/_index.html -> layouts/shortcodes/release-data.html
)In the future, SIG Release could move their data source to k/website and the process would be automated 100% with co-ownership between SIG Docs and SIG Release.
Other minor changes included in this PR
version-skew-policy.md
(addedtype: docs
)/docs/setup/version-skew-policy/ /docs/setup/release/version-skew-policy/ 301
changed to/docs/setup/version-skew-policy/ /releases/version-skew-policy/ 301
/docs/setup/release/ /releases/ 301
/docs/setup/release/version-skew-policy/ /releases/version-skew-policy/ 301
notes.md
(addedtype: docs
)/docs/setup/release/notes/
/docs/setup/release/notes/ /releases/notes/ 301
git.k8s.io/release/OWNERS_ALIASES
release-engineering-approvers
release-engineering-reviewers
data/releases/
,content/en/releases/
including the above approvers / reviewers.Open questions & items (non blocking)
versionSkew
shortcode could be improved to usedata/releases
vs.site.Params
(and math)config.toml
)?data/releases/schedule.yaml
)data/releases/schedule.yaml
with URLs (replacing what downloadkubernetes.com does)To update everything
Next steps
Does having data in /data/releases/ make the most sense? (localization?)release-x.y
websites to current page (update release handbook too)/kind feature
/cc @kubernetes/release-engineering @kubernetes/sig-docs-en-owners @mkorbi
/priority important-soon
/sig release
/sig docs
/language en
/hold for review