-
Notifications
You must be signed in to change notification settings - Fork 336
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
(Pre-)Release v2.2.0 Blog #1733
Conversation
content/en/blog/2023-12-07-flux-release-around-the-corner/index.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023-12-07-flux-release-around-the-corner/index.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023-12-07-flux-release-around-the-corner/index.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023-12-07-flux-release-around-the-corner/index.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023-12-07-flux-release-around-the-corner/index.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023-12-07-flux-release-around-the-corner/index.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023-12-07-flux-release-around-the-corner/index.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023-12-07-flux-release-around-the-corner/index.md
Outdated
Show resolved
Hide resolved
Targeting the release of this blog on Dec 7. We may wait to publish this until the v2.2.0 release is actually available, let's put this into a PR today so we can preview and go through reviews Signed-off-by: Kingdon Barrett <[email protected]>
85578bf
to
3689df3
Compare
Signed-off-by: Kingdon Barrett <[email protected]>
content/en/blog/2023-12-07-flux-release-around-the-corner/index.md
Outdated
Show resolved
Hide resolved
Signed-off-by: Kingdon Barrett <[email protected]>
Signed-off-by: Kingdon Barrett <[email protected]>
We can preview here: https://deploy-preview-1733--fluxcd.netlify.app/blog/ https://deploy-preview-1733--fluxcd.netlify.app/blog/2023/12/flux-v2-2-release-around-the-corner/ I think we might want to add a graphic? I'm reviewing the text now, if there are any more suggestions please go ahead and review. This is slated to be published today. (You have an opportunity to give me direct feedback at Bug Scrub, which starts in 10 minutes, and you won't have to type at all...) |
Signed-off-by: Kingdon Barrett <[email protected]>
I've heard this issue is being resolved: fluxcd/image-automation-controller#117 Details about which specific issues are being resolved are all being withheld for the next blog article. If any feedback wishes to highlight something else in this article, we can talk about it, but again, the target date to publish this is today. |
|
||
We hope many Flux users will rejoice in the improvements of the updated helm-controller, and that you'll all update to the latest release. This will help, in particular, with the issue of how the automatic recovery of Helm releases could occasionally get stuck in a pending state. | ||
|
||
Two new controls become available in the CLI (and as annotations) that can either [force](https://github.com/fluxcd/helm-controller/blob/64fed65148342578c1ed4b2155cd81852c54557a/docs/spec/v2beta2/helmreleases.md#forcing-a-release) or [reset](https://github.com/fluxcd/helm-controller/blob/64fed65148342578c1ed4b2155cd81852c54557a/docs/spec/v2beta2/helmreleases.md#resetting-remediation-retries) the `HelmRelease`. |
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 refers to documentation which hasn't been merged, my intent was to use the information to enrich the post. Not to link to 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.
Maybe the best compromise here is to just not include the links, until the release is out, and then I'll add links in a follow-up commit. (This feedback right here is the reason why I thought it would actually be simpler to release this blog concurrent with the actual release, not ahead-of-time. How do we refer to these features without linking any docs?)
Of course we can just remove the links, if we're happy with the text. This is the pre-release blog, so I'm not sure how else we can make it comprehensive except to link to some docs which are not released yet.
We could try linking to pull requests instead of linking to docs that are unreleased? WDYT
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've pulled those unpublished references out into the footer so I don't lose track of them, but they are not links anymore.
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.
You refer to the features by providing a brief overview of what will be added or changed, or showcasing it. This would not require references to documentation.
I continue to feel that without doing any of this, the blog post is just void and doesn't warn people up in any way, nor would it tell people more than what is stated in the release notes. Which means I still do not get the point of publishing this in its current form.
Signed-off-by: Kingdon Barrett <[email protected]>
After discussing this more, we have landed on the following conclusion:
|
Targeting the release of this blog on Dec 7. We may wait to publish this until the v2.2.0 release is actually available
(Let's put this into a PR today so we can preview, make sure it looks good, and go through reviews - we can start preparing both blogs this way.)
The usual release blog comes out a while after the release, because everyone with an appropriate level of knowledge to write about what goes into the release is currently... working on the release! We'll do a more detailed and thorough post like we usually do, but we got feedback from users that we should link to the blog from the release notes, and we can only do that if the blog is out when the release comes out. Or, a blog. (We can update the blog link once the more detailed post is available, but we should establish this pattern of linking to the release blog from the release notes, if we want our conscientious users to find the blog post and the information in it when they are upgrading.)
I personally think we should wait to announce the release until it's out. The discussion around this post up until now was that we would aim for a target date, and the language reflects that the release is "coming soon." If we're going to post both concurrently, we should make some minor changes to the language to reflect that the release "is out" not "coming soon."
So, this is the pre-release blog. A separate PR will contain the release blog.