Turf semantic versioning

[morganherlocker]

I think we should move to a stricter interpretation of semver. Roughly what this means is:

major|minor|patch

• major: any change to an existing api interface
• minor: new modules or the addition of optional parameters
• patch: perf improvements

  questions

• Where do bug fixes fit in? In a library like Turf, bugs are often worked around, so "backwards compatibility" may be fuzzy.
• Where do algorithm output changes fit in? (example: turf-buffer switches from planar to geodesic output, but the api is unchanged)

  communicating the change

Under this scheme, major versions are going to be pushed often. We should explain why this is happening, and I think a good place to start is a VERSIONING.md file documenting how/why we use semantic versioning, along with explicit clarifications of the finer points.

turf@36.0.0

The main thing I want to keep in mind here is that major versions should not be clumped or avoided to keep the number low. That would slow development speed, which is something I want to avoid. If we make this switch, it needs to be a mundane thing to bump major. The version will be purely a semantic communication tool, not some sort of measure of progress or meta stability.

cc @lyzidiamond @tmcw

[tcql]

Where do algorithm output changes fit in? (example: turf-buffer switches from planar to geodesic output, but the api is unchanged)

I think that's a major bump there. Output is still part of the API, and output changes will certainly lead to breakage for some people (or at least unexpected changes in results)

[tcql]

Is the questions here still outstanding? I believe we've effectively made the switch, but we still need to add documentation about versioning

cc @morganherlocker @lyzidiamond @tmcw

[morganherlocker]

yep, we made the jump