Release strategy

[lukas-h]

• Is the described workflow from CD to pub.dev for releases branch #10 (comment) okay?

  1. New features with PR into main
  2. PR from main to releases (with new version in pubspec.yaml, as well as changes mentioned in CHANGELOG.md), triggers GitHub Actions: run tests and pub publish --dry-run.
     Branch releases is protected and PRs need at least one review.
  3. GitHub Action after merge: pub publish --force to pub.dev/packages/turf

• How are we naming versions, how do we decide which features are patches, minor, or major versions?
  semver.org

[baparham]

Coming from the NPM space, there is a really cool semantic automatic releasing tool/flow that relies on commit message prefixes to indicate what sort of version bump is needed. https://github.com/semantic-release/semantic-release

I wholeheartedly agree we should follow the semver standard, and at this point, until we are at feature parity (or close enough for practical purposes) to turf.js, we can probably increment the minor version whenever we add a new (non-breaking) feature, and increment the patch version whenever we fix or refactor existing features.

staying under 1.0.0 also allows us a bit of flexibility with changing the public API in minor versions, though we should avoid it if possible.

You release flow looks good for now, though soon-ish I'd like to try and automate it so we don't need to manually PR a release in the future.

[baparham]

I can't find an equivalent in the dart space yet, but we don't need quite that complex of a system I think, at least not quite yet.