-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Meta issue: breaking style spec changes #6584
Labels
breaking change ⚠️
Requires a backwards-incompatible change to the API
cross-platform 📺
Requires coordination with Mapbox GL Native (style specification, rendering tests, etc.)
Comments
This was referenced May 1, 2018
Closed
jfirebaugh
added
breaking change ⚠️
Requires a backwards-incompatible change to the API
cross-platform 📺
Requires coordination with Mapbox GL Native (style specification, rendering tests, etc.)
labels
May 1, 2018
In case anyone is interested in seeing what it's like working with camelCase rather than kebab-case (ie, #4163), I made this utility library: https://www.npmjs.com/package/mapbox-gl-utils. It also takes care of #4160. It's a pretty nice improvement :)
|
1 task
This was referenced Jul 13, 2021
9 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
breaking change ⚠️
Requires a backwards-incompatible change to the API
cross-platform 📺
Requires coordination with Mapbox GL Native (style specification, rendering tests, etc.)
The Mapbox GL ecosystem is now wide and deep; breaking changes can have rippling consequences, imposing costs on many downstream components. This is particularly true for changes to the style specification, which by their nature will typically affect gl-js, gl-native core, the native SDKs, Mapbox Studio, Mapbox web services, documentation and customer support, and innumerable utilities, plugins, and applications, both those maintained by Mapbox and those written by customers and open source users.
It therefore seems unlikely that we'll make breaking changes to the style spec in the future, unless they provide a substantial benefit to compensate for these costs. In particular, "cosmetic" breaking changes, such as renaming a style property, are unlikely to meet this bar.
It remains a possibility that at some future date we'll make a coordinated effort to produce a "v9" version of the style specification that aggregates many of these breaking changes in one major release, hoping that by making them simultaneously, we can reduce the overall cost in exchange for their combined benefits. Therefore this "meta issue" collects such issues, previously tracked individually. After being listed here, the individual issues will be closed, in order to keep our issue count more manageable. Feel free to add additional issues to the list.
The text was updated successfully, but these errors were encountered: