Clean up rstar versioned dependencies #759
Conversation
Explicitly declare `rstar_0_8` and `rstar_0_9` to make it clearer which version is being used. For backward compatibility, the `rstar` is now a feature that enables `rstar_0_8` TBD: does this need a changelog message, and if so, what kind of text is expected?
| use-rstar = ["rstar", "approx"] | ||
| # Prefer `use-rstar` feature rather than enabling rstar directly. | ||
| # rstar integration relies on the optional approx crate, but implicit features cannot yet enable other features. | ||
| # See: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#namespaced-features |
There was a problem hiding this comment.
from https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#namespaced-features
Namespaced features has been stabilized in the 1.60 release.
Nice! So in 4 releases (~24 weeks) we could think about utilizing them.
There was a problem hiding this comment.
(unrelated to your PR, I know... the diff just caused me to check the link)
|
bors r+ thanks! |
759: Clean up rstar versioned dependencies r=michaelkirk a=nyurik Explicitly declare `rstar_0_8` and `rstar_0_9` to make it clearer which version is being used. For backward compatibility, the `rstar` is now a feature that enables `rstar_0_8` TBD: does this need a changelog message, and if so, what kind of text is expected? - [x] I agree to follow the project's [code of conduct](https://github.com/georust/geo/blob/master/CODE_OF_CONDUCT.md). - [ ] I added an entry to `CHANGES.md` if knowledge of this change could be valuable to users. --- Co-authored-by: Yuri Astrakhan <[email protected]>
|
bors r- Oh, right, the changelog... Your GH message seems pretty close to a useful changelog message. I'd recommend proposing something based on that. |
|
Canceled. |
|
Umm, the plan was to drop the plain |
Can you clarify what you mean by "minor" - it's a bit confusing because geo-types is 0.x.y In #682 (comment) you and @rmanoka discussed it, and it seems like you agreed to remove it in the next breaking release. |
|
Next minor as in 0.20.0 (0.19.1 would be a patch release). What I mean to say is that if we're expecting to merge soon other breaking changes, it's not worth doing this. If we plan to put out a 0.19.1 at some point, then it's fine. |
What other breaking changes are we planning to merge soon? Can you clarify what you'd like to see happen with this PR @lnicola? I'm a bit confused because you approved it, but now it seems like you're saying you'd prefer not to merge it. |
|
My goal for this PR was purely a cleanup without any visible changes. We can later figure out if we want any breaking or non-breaking changes, if anything should be removed/renamed/... |
thx @michaelkirk , done |
I don't think I've checked every open PR, but #751 is breaking AFAICT.
No preference, I was just pointing out that we might have to update this again (and remove it form the changelog) if we merge another breaking change before the next release. Even in that case, this PR is fine, which is why I approved it. |
|
Thanks for clarifying @lnicola - sometimes I have a hard time understanding people on the internet. |
Co-authored-by: Michael Kirk <[email protected]>
|
Are there any blockers for this noop PR? Seems like all comments have been resolved? |
|
The changes here are good. I think we should also drop the deprecated feature, but that's a different discussion. bors r+ |
|
@lnicola I think your bors-foo is not as strong as @michaelkirk 's ;) |
|
So you broke github too? Nice :) |
|
Build succeeded: |
Explicitly declare
rstar_0_8andrstar_0_9to make it clearer which version is being used. For backward compatibility, therstaris now a feature that enablesrstar_0_8CHANGES.mdif knowledge of this change could be valuable to users.