Publish first release to NPM: maplibre-gl@1.13.0

[nyurik]

Once all other work in the first release project is done, publish the resulting code to NPM.

I have created a placeholder maplibre-gl NPM package.

@MapLibre/core please let me know your NPM user names so you can be added to the list of maintainers there.

[lseelenbinder]

I'm lseelenbinder.

[snickell]

I'm snickell

[snickell]

@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)

[snickell]

OK, I'm focused on building and releasing maplibre-gl-js v1.13.0-rc.1 now

[snickell]

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

[snickell]

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?

[snickell]

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

[snickell]

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.

[snickell]

UPDATE: I believe that the primary (only?) thing blocking us from being ready to release maplibre-gl@1.13.0 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.

[nyurik]

@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.

[snickell]

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

[snickell]

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.

[klokan]

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.

[snickell]

@klokan I second that

[lseelenbinder]

Agreed.

[klokan]

Published at https://www.npmjs.com/package/maplibre-gl as 1.14.0