# SemVer Compatibility Tool - GSoC Proposal Draft and Discussion **URL:** \ **Category:** cargo\ **Created:** [March 6, 2017, 10:40pm UTC](https://internals.rust-lang.org/t/semver-compatibility-tool-gsoc-proposal-draft-and-discussion/4926 "2017-03-06T22:40:15Z")\ **Posts on this page:** 1\ **Showing post:** 17
**Author:** ![brson](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/brson/32/5197_2.png) [@brson](https://internals.rust-lang.org/u/brson)\ **Post date:** [March 9, 2017, 3:12am UTC](https://internals.rust-lang.org/t/semver-compatibility-tool-gsoc-proposal-draft-and-discussion/4926/17 "2017-03-09T03:12:07Z")
Hi @twk. I’m really impressed with the legwork you’ve done here. This is a strong way to approach these GSoC proposals - it gives a lot of confidence. It looks to me like you’ve gotten a lot of good advice. Generally, I think you should focus on the algorithm. That is the hard problem here and I suspect one could spend much more than a single season getting it correct. That’s not to say it shouldn’t have a usable interface. But it would not be the best use of your time getting bogged down in specifying new compiler interfaces. Clippy is a good project to immitate here. It is a custom rustc driver that sets up the compiler pipeline in memory and modifies it to whatever ends it needs. You can do a lot this way, out of tree, and it’s an appropriate approach for speculative Rust compiler projects. You might think a bit, and write a bit, about how you will validate and test your system. You might also look to prior art for ideas. I think Elm does this. --- _[View the full topic](https://internals.rust-lang.org/t/semver-compatibility-tool-gsoc-proposal-draft-and-discussion/4926)._