search

BurntSushi / quickcheck

Automated property based testing for Rust (with shrinking).
The Unlicense
2.4k stars 149 forks source link

Fix broken link #192

Closed ethanpailes closed 6 years ago

ethanpailes commented 6 years ago

I noticed this link was broken while reading through the docs.

I'm not completely happy with the doc link I added because it is pinned to a specific version rather than the latest version, which I think would make more sense for a reference from the head of master. Do you happen to know if there is a know good way to deal with this problem? If not it might be worth asking the docs.rs maintainers to add the ability to name the latest version with a URI.

ethanpailes commented 6 years ago

Actually, I just noticed that you have burntsushi.net configured to redirect to the latest, which is a clever workaround. I suppose a more principled fix might be to make the struct link on burntsushi.net redirect to the latest version. If you want to go that route, this PR is not required.

BurntSushi commented 6 years ago

Yeah I definitely want to migrate everything over to docs.rs. I setup the redirect in the likely event that I didn't catch everything. :-) Thanks!

ethanpailes commented 6 years ago

I actually think the redirect is a really nice solution to the fact that docs.rs does not seem to have a way to talk about the latest version. When you cut a new point release you just have to update your redirect without having to add changes to the README. Of course it would be better if docs.rs had the ability.

ethanpailes commented 6 years ago

Wait, it turns out I just forgot to read the manual. There is a way. I can go through and update links if you want.

BurntSushi commented 6 years ago

@ethanpailes Technically, the links in the README should be versioned. That way, you always get the right docs no matter which version of the README you're reading. The "problem" is remembering to update all of the links when the version gets bumped. :)

ethanpailes commented 6 years ago

I hadn't thought of the rooting-through-git-history use case. Now that you mention it, the current situation seems like the best approach. I guess release tooling would solve the issue? That seems like way too much overkill.