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.

Sign up for GitHub

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

Jump to bottom

Nitpicking the 8.0 Breaking Change issue template #81678

Merged
merged 2 commits into from
Oct 26, 2020
Merged

Nitpicking the 8.0 Breaking Change issue template #81678

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
0998143
Nitpicking the 8.0 Breaking Change issue template
kobelb Oct 26, 2020
fa28829
Rewording the percentage of users impacted question
kobelb Oct 26, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 6 additions & 5 deletions .github/ISSUE_TEMPLATE/v8_breaking_change.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
name: 8.0 Breaking change
about: Breaking changes from 7.x -> 8.0
title: "[Breaking change]"
labels: Team:Elasticsearch UI, Feature:Upgrade Assistant
labels: Team:Elasticsearch UI, Feature:Upgrade Assistant, Breaking Change
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I added the "Breaking Change" label to differentiate these from the other issues associated with the Upgrade Assistant. This would be a new label, I'm not tied to the name. I also considered making it Feature:Upgrade Assistant - Breaking Change. Any preference or thoughts on a different way to classify the two different types of issues?

Copy link
Contributor

Choose a reason for hiding this comment

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

Love it! What do you think of using the "Breaking change" label as a dimension for categorizing it by how it will be surfaced? We can create three labels:

Breaking Change
Breaking Change:Deprecation Log
Breaking Change:Deprecation API

By default, we can apply Breaking Change via this template. As these issues are created we'll triage them by swapping this label out for one of the others. Or do you think this overloads the label too much / adds too much complexity?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sounds good to me!

assignees: ''

---
Expand All @@ -11,15 +11,16 @@ assignees: ''

**Which release will ship the breaking change?**

<!-- e.g., v7.6.2 -->
8.0
Copy link
Contributor Author

Choose a reason for hiding this comment

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

The issue template states that it's an 8.0 breaking change, so it feels like this will be 8.0 for all of these? Or perhaps we should change Which release will ship the breaking change? to Which release first included the deprecation?, but I'm not sure how the answer to this new question impacts anything.

Copy link
Contributor

Choose a reason for hiding this comment

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

Good call hardcoding this in here. I don't think we'll ever encounter a scenario where we'll need to change this between now and the time 8.0 is GA.


**Describe the change. How will it manifest to users?**

**What percentage of users will be affected?**
**How many users will be affected?**

<!-- e.g., Roughly 75% will need to make changes to x. -->
<!-- e.g., Based on telemetry data, roughly 75% of our users will need to make changes to x -->
<!-- e.g., A majority of users will need to make changes to x. -->

**What can users to do to address the change manually?**
**What can users do to address the change manually?**

<!-- If applicable, describe the manual workaround -->

Expand Down