Branching strategy and NuGet versioning

[ryanspain]

Currently

• Most (if not al) pull requests target the main branch.
• The NuGet package is published from release/* branches.
• The NuGet package versioning is semantic. i.e. 1.0.6.

A problem with this approach is that we need to back track and create a release/* branch to get the changes published in the NuGet package.

Proposal

We introduce a "pre-release" NuGet package.

• Pull requests will target a new dev branch and be integrated quickly.
• The pre-release NuGet package will be published from the dev branch per commit/merge.
• The NuGet package version will be post-fixed with -beta, -dev, or similar. See pre-release versions for ideas. i.e. 1.0.6-dev.
• The <Version> of the dev branch will be ahead of main, but subject to semantic versioning. e.g. breaking changes, bug fixes.

Rational

This library is under active development; a pre-release NuGet package version is a good way to protect the release package version from breaking changes while allow active developer to contribute to the next big release.

Changes to developer flow

• Developers actively using and contributing to the library can update their projects to target the pre-release NuGet package version (e.g. 1.0.6-dev).

---

Would love to hear feedback from all: @MatejMa2ur, @kjoergensen-foreflight, @kubikpatrick, @mlidodo.

[kubikpatrick]

personally, i like the idea, i'm kinda a newbie with github so keeping two different branches for the lib would be perfect

however, we should warn futur contributors somewhere that they should clone/fork the dev branch

[MatejMa2ur]

Hi yep i am down for changing it I think having dev as the default branch and main for releases is also clear what where.

With the publishing automatically, i kinda like it.
I am just not sure how many pre release versions we need and will be used. Because there are a lot of features in the original MapLibe GL JS library. And some of them are already moved over.

But overall i am down for this change.

[ryanspain]

I am just not sure how many pre release versions we need and will be used. Because there are a lot of features in the original MapLibe GL JS library. And some of them are already moved over.

Great points @MatejMa2ur! What I had envisioned was just a single pre-release package. Think of it like the vNext version. The next version we are working towards. e.g. 1.0.6-dev. No iterations of dev, just simply the dev build of the project. We can increment the semantic portion of the version label as normal.

I know you talked about versioning in a related issue (#73), matching the MapLibre version number. And I think this is a good idea, but for now, maybe we try and get parity with the library (or at least as close as possible), then bump up to match the version some time. At that point we can just try and keep up with MapLibre, but reserve patches for improvements and bug fixes. Hopefully the option for extensibility via plugins will help keep the core library as lean as possible.

[MatejMa2ur]

Oh yep, feel free to write in the main comment, I just use phone app, and I didn't knew how to respond to main thread :)