-
Notifications
You must be signed in to change notification settings - Fork 316
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
Release notes automation and integration #3609
Comments
cc @fengjiachun @MichaelScofield @waynexia @sunng87 @killme2008 Please drop a comment for your opinions. Hopefully, the process should be activated from v0.8.0. cc @Wenjie0329 @nicecui @alili for your information. |
LGTM, we can start from the new versions? |
Hey, maintainer of |
@fengjiachun GreptimeTeam/docs#862 is ready for review as a sample of release note. I suggest we catch up release notes for 0.7.0 and 0.7.1 so that in the next version we know what should be focused and possibly improved. |
@orhun Thank you! Let me try it out first. I'll ping you if there is any uncertain :P |
Some of the content has to be moved out to be version-agnostic, like changelog, faq and all cloud docs (cloud can be considered as rolling-release). Not 100% sure if it's possible with our doc site. Perhaps we can use symbolic link for that? |
Ref - GreptimeTeam/docs#871 Seems lint-staged doesn't like symlink. |
Closed as resolved. |
Motivation
Currently, our changelog page doesn't have real change logs but links to the latest roadmap and biweekly report.
From another perspective, our patch releases do not provide comprehensive release notes for users, like:
Thus, I suppose we resolve these two issues:
Proposal
Doc site structure
Update the current structure:
to:
Release note generation and publish
Generation
This is a part that needs to be determined. And I'd prefer to delegate the choose to RMs at least for the first few releases.
These release notes can be referred:
To be clear, separate the updates into a few sections with human-readable changelog messages. Highlight the important updates, esp. critical fixes, breaking changes, and deprecations.
We have a few tools to help:
Note
All of this release notes things doesn't change how we make GitHub releases now. Whether the GitHub releases page should be left as is or changed, is not included in this proposal.
Publish
It should be the same as the current docs update process. That is, the RM revises release notes, sends a patch to add a new page under
Releases/vX.Y.Z
, and pings @nicecui and @GreptimeTeam/marketing for review.Open questions
The text was updated successfully, but these errors were encountered: