Dealing with a breaking rstar release

[urschrei]

The next rstar release (when we decide to cut it) will be breaking (georust/rstar#189). This will mean we have to maintain a new set of macros for the new API (IIUC). This is highly annoying. Is there a deprecation path we can take here? I have a suspicion (not easily verifiable, granted) that there isn't much use of older rstar versions, and I'd love to start moving those users who do exist into the "new world" and set a date (in the proximate future! 2027!) when we cut over entirely to the new API.

[michaelkirk]

We have accrued a lot of versions, but updating an optional dependency doesn't seem like a great reason to break geo-types semver in my opinion.

I'm willing to have a go at implementing the new bothersome macro. I'm sure it will be annoying, but hopefully only moderately, as opposed to highly. Coordinating a bunch of downstream crates with a major version bump seems likely to be more annoying in my estimation.

[michaelkirk]

Alternatively we could yolo and just implement #15 😆 - I'm not sure what the capacity for boat rocking is.

[urschrei]

Hum. How serious are we about actually tackling #15?

[michaelkirk]

🤷

I don't really know. I'm definitely more than zero serious. I'm pretty conservative, but the unnecessary Point/Coord distinction haunts me.