chore: new year, new emoji 🚀

[wjhsf]

Details

I don't like "✅ No". Also, it's slightly inconvenient that ⚠️ displays in text-mode in the editor but emoji-mode in the actual post.

Does this pull request introduce a breaking change?

• ✅ No, it does not introduce a breaking change.
• 🚨 Yes, it does introduce a breaking change.

Does this pull request introduce an observable change?

• ✅ No, it does not introduce an observable change.
• ⚠️ Yes, it does include an observable change.

GUS work item

[nolanlawson]

Huh, I thought this could be fixed with the variation selector character, but I guess not:

<-- with variation selector -->
⚠️

<-- without -->
⚠

[nolanlawson]

We could also just replace the whole thing with "No, it does not introduce a breaking or observable change" vs "Yes, it does introduce a breaking or observable change"

For us, "observable" means "breaking" if it's in the context of component authors. I don't think there's much of a distinction between the two for us TBH.

[jye-sf]

I do feel like we have changes that are observable but not breaking though:

• new features (default exports)
• dx related changes where we don't support taking a programmatic dependency (error messages)
• compiler changes/fixes (static parts fix)

That said, I'm open to reconsidering whether we need these distinctions on every PR as an emoji + text. My 2 cents are that there's overlap, but there are slightly different decision paths happening:

• observable -> double check whether/how this could be breaking to someone. Consider how this should be communicated to customers through readme notes or docs.
• breaking -> consider communication (overlaps with observable changes), rollout plan, and potential fallout.