Rename Mapbox packages to Maplibre

[Patrick-Kladek]

Motivation

As decided in the maplibre-navigation call on 12th June we will rename the last packages from Mapbox to Maplibre.

Here are the meeting notes:
https://docs.google.com/document/d/1RIHlPLvCzNr6hXXJtMY8uThIAb9nIzeS54KRn79KCHw/edit#heading=h.gvqnt0woh9ts

[michaelkirk]

Since this is going to be breaking, do people want this to happen before the v3.0 release? If so I could make time to work on it in the coming days.

[michaelkirk]

One concern is #54, which will likely encounter some conflicts if we rename the library before it's merged. I wouldn't feel great about foisting conflicts on you @Patrick-Kladek. The alternative would be to quickly follow up with another breaking (v4) release. Maybe that's fine though — I don't personally lose too much sleep over bumping the major version.

[boldtrn]

Since this is going to be breaking, do people want this to happen before the v3.0 release? If so I could make time to work on it in the coming days.

We talked about that yesterday as well. So right now the plan would be to release 3.0 tomorrow (unless something critical comes up). If you see a serious issue, let us know (and I think #57 could be a show stopper?) I think @Patrick-Kladek would like to merge #54 ASAP and I think we should not merge such a huge change just before releasing 3.0.

We can always release 4.0 with more breaking changes. WDYT?

[hactar]

I think this sounds like a good approach: we never did a (non beta) release of the SPM release - so why not do that, as a "final" release before we all started ripping it apart and making it better. I think that way people will feel less worried about the breaking changes - and these breaking changes are very important to keeping MapLibre Navigation up to par with modern navigation apps. So a 3.0 release based on what we have, quickly followed by a 4.0 release as a new major milestone to work from.

[Patrick-Kladek]

So a 3.0 release based on what we have, quickly followed by a 4.0 release as a new major milestone to work from.

I think that's the most reasonable approach

[michaelkirk]

I'm fine to follow up with a 4.0 release.

I fixed #57 in #58.

Unfortunately It's not exactly a trivial fix. There were several different things critically wrong with it.