Comments (16)
I'd like to follow a release principle as follows:
- 100% compat on our first release, which means we completely inherit mapbox-gl-js v1.13 as if it was our own release
- Treat mapbox features we can’t/won’t support long-term (like mapbox namespace in JS) as a “deprecation”
- Warn agressively about using deprecated things, and have a deprecation schedule (say, 6 mos), as if we were actually deprecating from the previous version
- Finally, release maplibre-gl 2.0, which based on semver breaks our deprecations: no more mapbox: URIs, no more support for dist/mapbox-gl.js , no more importing from the mapbox namespace
In other words, to be a true successor to mapbox-gl v1.13, we should treat v1.13 as if it was a release WE made, and follow a deprecation schedule policy for all changes from that (including api renames from mapbox
), and respect semver.
This will serve our users best, minimize disruption in their lives, and increase the number of people who "upgrade really quick and easy" vs wait and see.
@petrsloup @nyurik @lseelenbinder
from maplibre-gl-js.
I propose the first stable release of GL JS to be 1.14.0 - as proposed in #95 and as in the meanwhile Mapbox did 1.13.1.
from maplibre-gl-js.
I'm lseelenbinder.
from maplibre-gl-js.
Published at https://www.npmjs.com/package/maplibre-gl as 1.14.0
from maplibre-gl-js.
I'm snickell
from maplibre-gl-js.
@nyurik do you also have the @maplibre org on npm? It might make sense to namespace all our packages under an org, while this is slightly different from how mapbox does it, I suspect it'll result in more ease and consistency for us (I suspect mapbox created their package names before this was common practice)
from maplibre-gl-js.
OK, I'm focused on building and releasing maplibre-gl-js
v1.13.0-rc.1 now
from maplibre-gl-js.
This PR contains a rough doc of the steps I was using to build maps-gl releases yesterday:
https://github.com/maplibre/maplibre-gl-js/blob/f8eefddade0502865a18b7d0274fd2d6adc74231/docs/making-a-release.md
from maplibre-gl-js.
I just published the first release candidate experiment to npm: https://www.npmjs.com/package/maplibre-gl/v/1.13.0-rc.0 [update: use latest one published below]
Could folks give it a try and report back?
from maplibre-gl-js.
There are potentially legal considerations to discuss here. I don't think its immediately clear that we can't safely+legally support, e.g. import mapboxgl from 'mapbox-gl'
when using our package, particularly as we transition.
from maplibre-gl-js.
UPDATE: I believe that the primary (only?) thing blocking us from being ready to release [email protected] is getting enough test reports that RC3 is working as a perfect replacement: https://www.npmjs.com/package/maplibre-gl/v/1.13.0-rc.3
So please test it everyone!
It would also be great for v1.13.0 if @lseelenbinder put together an edit to the readme documenting briefly (assuming other people agree) to do responsible stewardship and aim for slow gradual api changes with advanced notice and deprecation policies moving forward.
from maplibre-gl-js.
@nyurik do you also have the @maplibre org on npm? It might make sense to namespace all our packages under an org, while this is slightly different from how mapbox does it, I suspect it'll result in more ease and consistency for us (I suspect mapbox created their package names before this was common practice)
Before we do a final release, lets decide if we should either keep the Mapbox packaging structure (maplibre-gl as a top-level package, while smaller libraries namespaced under @maplibre/*
), or if we should break from that pattern (place everything into @maplibre/*
namespace).
My personal preference is to keep the same pattern as Mapbox to simplify migration (files will be placed in the same node_modules depth, etc), but I'm ok if we decide to abandon it from the start.
from maplibre-gl-js.
I felt like namespacing is a close call, so its only a mild preference on my part, and I see good arguments either way. For developer ergonomics, I think non-namespaced wins, and when in doubt "don't make changes now" :-)
So I think I'm changing my vote to: stick with what we have now, non-namespaced
from maplibre-gl-js.
There's some "easy to find other things from the same project" advantages to @maplibre/maplibre-gl
, but it adds more things to remember when you type a require/import statement from memory. I think that small difference makes maplibre-gl
a winner.
from maplibre-gl-js.
@klokan I second that
from maplibre-gl-js.
Agreed.
from maplibre-gl-js.
Related Issues (20)
- Having trouble writing a working `addProtocol` for a raster layer HOT 1
- Recoloring a raster source like a WMS or image. Such as in mapbox: raster-color & raster-color-mix HOT 7
- Modifying the results of map.getStyle() modifies the style HOT 1
- `line-width` is incorrectly rendered when used in conjunction with `line-offset` in certain line angles HOT 3
- 3D Terrain significantly decrease performance of the map HOT 2
- Use a secondary tile source for a specific bbox only HOT 1
- Per-feature fill-extrusion-opacity HOT 1
- Add 3DTiles as source for terrain layer HOT 2
- setFeatureState changes type of properties from feature and changes evaluation of unrelated properties. HOT 1
- Rendering of vector tiles in wrong y-order HOT 2
- [Feature] Allow "underzooming" to show entire map on non-square viewports when renderWorldCopies=false HOT 13
- Modularize graphics backend
- Can't disable all sky rendering when terrain is enabled HOT 1
- [Add 3D model Babylon]Part of 3D model which is with negative y is not visible HOT 1
- v4.0.0 silently swallows errors in load event HOT 3
- spector.js no longer able to capture a frame with maplibre-gl-js HOT 2
- 3D map freezes when camera is adjusted against map bounds (in dev environment only (?)) HOT 4
- Replace some manual script detection with regular expressions HOT 1
- Node 22 build issue - Import Attributes
- Hill Shading: Artifacts on Linux HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from maplibre-gl-js.