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

Docs: How to version UI extensions #1521

Merged
merged 32 commits into from
Feb 20, 2025
Merged

Conversation

mckn
Copy link
Collaborator

@mckn mckn commented Feb 7, 2025

What this PR does / why we need it:
This aims to provide some good guide lines for how to version your extension points to allow plugin authors to change the extensions without breaking any plugins consuming the extension point.

Todo:

  • Add a first draft for how to work with versions
  • Add step-by-step examples for both plugin extensions and components.

Which issue(s) this PR fixes:
Fixes grafana/grafana#92202

Fixes #

Special notes for your reviewer:

@mckn mckn requested a review from a team as a code owner February 7, 2025 14:51
@mckn mckn requested a review from s4kh February 7, 2025 14:51
Copy link

github-actions bot commented Feb 7, 2025

Hello! 👋 This repository uses Auto for releasing packages using PR labels.

✨ This PR can be merged. It will not be considered when calculating future versions of the npm packages and will not appear in the changelogs.

@mckn mckn marked this pull request as draft February 7, 2025 14:56
@mckn mckn self-assigned this Feb 7, 2025
@mckn mckn added type/docs Changes only affect the documentation no-changelog Don't include in changelog and version calculations labels Feb 7, 2025
@mckn mckn requested a review from sympatheticmoose February 7, 2025 14:58
@josmperez josmperez self-requested a review February 10, 2025 21:22
Copy link
Contributor

@josmperez josmperez left a comment

Choose a reason for hiding this comment

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

Very nice doc! A question and a few minor style nits, otherwise LGTM. For future reference, emphasis isn't so necessary -- and we use italics instead of bold for emphasis.

mckn and others added 17 commits February 13, 2025 20:28
@mckn mckn marked this pull request as ready for review February 13, 2025 20:25
@mckn mckn requested review from jackw and leventebalogh February 17, 2025 10:23
Copy link
Collaborator

@jackw jackw left a comment

Choose a reason for hiding this comment

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

LGTM! 🚀

Copy link
Collaborator

@leventebalogh leventebalogh left a comment

Choose a reason for hiding this comment

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

Nice one @mckn 🚀

Copy link

@jarben jarben left a comment

Choose a reason for hiding this comment

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

LGTM!

Copy link
Contributor

@sympatheticmoose sympatheticmoose left a comment

Choose a reason for hiding this comment

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

Overall this is looking good! I've made a few comments and suggestions which I would appreciate your thoughts on prior to merging


Each extension point ID/component ID should include a suffix indicating the major version of the extension.

**Example:**
Copy link
Contributor

Choose a reason for hiding this comment

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

non-blocking - it would be nice to have both an extension point and component example to be more explicit

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

So I started on this and it gets a bit complex to include it in the docs. I will create an issue adding it to examples (not sure I will have time before parental leave) and then reference that example in this doc. Sounds ok?

Copy link

@jewbetcha jewbetcha left a comment

Choose a reason for hiding this comment

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

Thanks for doing this!

Copy link

@manderson-dev manderson-dev left a comment

Choose a reason for hiding this comment

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

Looks like a good approach. This will take some coordination to start using.

I'm thinking we can start by adding /v1 to all our machine-learning exposed extension points, and leave the current ones there also, then ask other teams consuming our extensions to swap over to the /v1 version.

It'll be a good way to get everyone used to it.

Thanks for doing this, it'll help us a lot when introducing changes that could have impact in lots of places.

@mckn
Copy link
Collaborator Author

mckn commented Feb 19, 2025

Looks like a good approach. This will take some coordination to start using.

I'm thinking we can start by adding /v1 to all our machine-learning exposed extension points, and leave the current ones there also, then ask other teams consuming our extensions to swap over to the /v1 version.

It'll be a good way to get everyone used to it.

Thanks for doing this, it'll help us a lot when introducing changes that could have impact in lots of places.

Super! We decided to consider the grafana-core extension points as v1 even tho they don't have the version suffix. When we need to introduce a breaking change we will create an en extension point Id with the v2 suffix.

@mckn mckn merged commit 93f2b12 into main Feb 20, 2025
16 checks passed
@mckn mckn deleted the mckn/ui-extensions-versioning-docs branch February 20, 2025 20:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
no-changelog Don't include in changelog and version calculations type/docs Changes only affect the documentation
Projects
Status: 🚀 Shipped
Development

Successfully merging this pull request may close these issues.

Extensions: versioning strategy for extensions
9 participants