Publish first release to NPM: [email protected] about maplibre-gl-js HOT 16 CLOSED

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.