[GitHub] [superset] eschutho commented on issue #12566: [SIP-57] Proposal for Semantic Versioning

[GitBox <gi...@apache.org>]

eschutho commented on issue #12566:
URL: https://github.com/apache/superset/issues/12566#issuecomment-763161857


   > Thank you for the comphrensive writeup! I learned a lot from reading this.
   > 
   > Some thoughts on a first pass:
   > 
   > > * Feature or Config Flags
   > >   
   > >   * Setting a new flag where the default would break any existing functionality
   > 
   > We should never allow a new flag to change the default. A feature flag is like an A/B test, it should only add or change features when the flag is set to true, and the changes should not start as the default.
   > 
   > > -UI
   > > 
   > > * changes that would break existing charts, dashboards, queries, or favorites
   > 
   > Would love to see an expansion on this, i.e., how the UI may break. For example,
   > 
   > * Changes that removes an existing functionality
   > * Changes that breaks an existing workflow without providing a clear alternative or requires user intervention for the alternative to be applied.
   > 
   
   
   Thanks for the feedback @ktmud. I removed ` Setting a new flag where the default would break any existing functionality` since that is a discouraged practice anyway and added in more information around breaking UI changes. I think it is going to largely be a judgement call on that topic. Hope this definition helps give some clarity while still leaving it open for interpretation. We can continue to tweak it as well.
   
   > We should also start thinking about breaking changes for the plugin systems, e.g., how the controls are defined, how query objects are built, and how charts are rendered... Currently it's in a "use at your own risk" state, but as the API matures, we may want to define any updates to `superset-ui` and the viz control related code in `superset-frontend` that break an existing viz plugin to be also a breaking change.
   
   Yeah, I was thinking about NPM plugins for example, and I noticed that we didn't have any peer dependencies, so that didn't seem to be an issue. Other than maybe node and NPM itself, I didn't find any other conflicts with the system that was running Superset. We don't have any specific node or npm/nvm version requirements other than to use the "latest", so there's no obvious way to know if it's breaking. Everything else in the npm modules should be self-contained within the package-lock file. Other than that, I'm not familiar with any breaking changes with superset-ui. As long as we are properly bumping the dependency in superset, is there anything else that the user should be aware of? 
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org