Closed ripytide closed 3 months ago
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.
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
andAsPixels
traits that then also broke many other bits of code such asimpl AsRef for RGB<T>
which internally uses theas_slice()
provided byComponentSlice
.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 emptylib.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 undersrc
and then I can start re-writing them using the0.8
as a guide`.