Clean-Room vs Conversion `0.9` migration work.

[ripytide]

While attempting to begin work on the accepted tracking issues I have found it quite difficult to make atomic changes as I had hoped. For example, when removing the ComponentBytes, ComponentSlice and AsPixels traits that then also broke many other bits of code such as impl AsRef for RGB<T> which internally uses the as_slice() provided by ComponentSlice.

It was at this point that I thought that making atomic changes would be a lot more effort than it was worth. Instead of slowly converting the previous implementation to make all the improvements for 0.9 can I instead do a clean-room re-implementation where I start with an empty lib.rs and then only migrate over things that we want to keep?

Ideally, both strategies (clean-room vs conversion) would arrive at the exact same result, however, I think they carry different risks. Clean-room is easier but risks not migrating desirable items/behavior, whereas conversion risks keeping undesirable items/behaviour.

I would like to go with the clean-room strategy since adding desirable items/behaviour can easily be done backwards-compatibly whereas removing undesirable items cannot and would require breaking changes or deprecation which is a lot messier.

If this is acceptable I'd like to send a nuke PR to the 0.9 branch that removes all files under src and then I can start re-writing them using the 0.8 as a guide`.

[kornelski]

Whatever works for you.

But keep in mind that this crate exists for interchange, and backwards compatibility is very important, so don't get carried away too far with a redesign, because there needs to be a smooth migration path for existing users.