Skip to content
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

chore: Updates CHANGELOG.md with 4.0.2 data #29600

Merged

Conversation

michael-s-molina
Copy link
Member

SUMMARY

Updates CHANGELOG.md with 4.0.2 data. It also updates the versions selector of the issue template.

ADDITIONAL INFORMATION

  • Has associated issue:
  • Required feature flags:
  • Changes UI
  • Includes DB Migration (follow approval process in SIP-59)
    • Migration is atomic, supports rollback & is backwards-compatible
    • Confirm DB migration upgrade and downgrade tested
    • Runtime estimates and downtime expectations provided
  • Introduces new feature or API
  • Removes existing feature or API

@dosubot dosubot bot added the doc Namespace | Anything related to documentation label Jul 16, 2024
## Change Log

### 4.0.2 (Wed Jun 26 14:26:58 2024 -0300)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Highlights of this patch release:
- New alerts & reports can now be saved, fixing [a widely-reported bug](https://github.com/apache/superset/issues/28149) introduced in 4.0.0.
- As a side effect of the fix in #29345, the y-axis ordering is now reversed on horizontal bar charts. Users who wish to retain the ordering they had in 4.0.1 can toggle the `Y-Axis Sort Ascending` box in a chart's editor view.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The commit title "fix(ar-modal): updateNotificationSettings not updating state" doesn't describe for most people that the alert & report modal now works again. I wanted to call that bugfix out specifically. And then note the change of behavior introduced by the other PR. These are the two things that felt to me like admins should know them, vs. other things that are more behind-the-scenes fixes.

Copy link
Member Author

@michael-s-molina michael-s-molina Jul 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sfirke I believe every fix is a highlight of a particular importance depending on if you are being affected by the fix. It's the responsibility of the PR author to write a good PR title/description, so I suggest editing the respective PRs to include more context instead of changing the template of the CHANGELOG.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking of a mini-version of release notes, like https://github.com/apache/superset/blob/master/RELEASING/release-notes-4-0/README.md for 4.0.0. I don't mean to mess with the CHANGELOG template; is there a place such mini release notes could go?

Not to take away from the other PRs, but objectively there are many more people asking about the alert/report fix in Slack than any other PR in this release. And I don't expect anyone to click and read through every PR, which is what would be necessary to know about the side effect of the #29345 change with bars reordering. I had reported that as a bug b/c I was unaware of it being a known side effect; calling it out here might stop other people from being similarly confused.

I think it will benefit the project to call out these two, as it may reduce unnecessary GitHub issues and Slack questions. But I will admit I don't know where that should go.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't expect anyone to click and read through every PR

That's what we assume people will do with our current CHANGELOG template. Our CHANGELOG is automatically generated using the PR's titles, which I think will never be sufficient to fully understand the changes. One alternative would be to change our template to actually add meaningful descriptions that wouldn't require people to go the PRs. The problem with this is the amount of work necessary to produce such CHANGELOG and the possible effort duplication with well written PRs.

Considering our current template, that assumes that people need to check the PRs, I would suggest editing the poorly described PRs.

This may be a good topic for the next Town Hall.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, sounds good. Thanks for the explanation.

@michael-s-molina michael-s-molina merged commit 028e9c9 into apache:master Jul 16, 2024
35 of 36 checks passed
@github-actions github-actions bot added 🏷️ bot A label used by `supersetbot` to keep track of which PR where auto-tagged with release labels 🚢 4.1.0 labels Nov 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🏷️ bot A label used by `supersetbot` to keep track of which PR where auto-tagged with release labels doc Namespace | Anything related to documentation size/M 🚢 4.1.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants