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

Include 3rd party SDKs in sdk-support object? #4170

Closed
lucaswoj opened this issue Feb 1, 2017 · 6 comments
Closed

Include 3rd party SDKs in sdk-support object? #4170

lucaswoj opened this issue Feb 1, 2017 · 6 comments
Labels
cross-platform 📺 Requires coordination with Mapbox GL Native (style specification, rendering tests, etc.)

Comments

@lucaswoj
Copy link
Contributor

lucaswoj commented Feb 1, 2017

From @ahocevar on January 10, 2017 15:38

I was wondering if it would be desirable to include 3rd party SDKs like ol-mapbox-style in the sdk-support object. Something like

"sdk-support": {
  "basic functionality": {
    "js": "0.10.0",
    "android": "2.0.1",
    "ios": "2.0.0",
    "macos": "0.1.0",
    "ol-mapbox-style": "1.0.0"
  }
}

The advantage would be an up-to-date information on supported features for those SDKs, and a way for utilities like style editors to only offer features that are supported in the target SDK.

This idea was first discussed in openlayers/ol-mapbox-style#10. An alternative would be to fork the spec, but it might make sense to have this information upstream. If this is not the case, are there any other suggested ways that I might not have thought about?

Copied from original issue: mapbox/mapbox-gl-style-spec#652

@lucaswoj
Copy link
Contributor Author

lucaswoj commented Feb 1, 2017

From @tmcw on January 10, 2017 16:2

I'm not opposed to this idea technically, and think it's much better than implicitly requiring you to fork the project. The chief concern is maintenance, really: with the Mapbox SDKs, we have the ability to ask our coworkers to keep the sdk-support updated, and have the leverage of being coworkers.

If we do start including 3rd party projects, I think we'd need

  • An agreement that the support levels of those projects are kept up-to-date on a regular basis
  • And if those projects lose maintainership, as too many open source projects do, we remove them from the spec.

@lucaswoj
Copy link
Contributor Author

lucaswoj commented Feb 1, 2017

From @ahocevar on January 10, 2017 16:26

Thanks for your comment @tmcw. I'd be 100% supportive of the rules you suggest.

For keeping the support levels up to date, we can make update pull requests part of the release process.

If there is general agreement on such a procedure, is there anything I can help with for establishing it?

@1ec5
Copy link
Contributor

1ec5 commented Feb 3, 2017

If there is general agreement on such a procedure, is there anything I can help with for establishing it?

For the community-maintained Mapbox macOS SDK, all it took was a PR: mapbox/mapbox-gl-style-spec#641.

@1ec5 1ec5 added the cross-platform 📺 Requires coordination with Mapbox GL Native (style specification, rendering tests, etc.) label Feb 3, 2017
@ahocevar
Copy link
Contributor

ahocevar commented Feb 3, 2017

Cool, I'll submit a pull request too then. Thanks!

@ahocevar
Copy link
Contributor

Are you still accepting a pull request for this? I had planned to work on it in the next couple of weeks.

@jfirebaugh
Copy link
Contributor

Yes, we'll still accept a pull request for this @ahocevar.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cross-platform 📺 Requires coordination with Mapbox GL Native (style specification, rendering tests, etc.)
Projects
None yet
Development

No branches or pull requests

4 participants