Tracking Issue for v0.9

[ripytide]

This is a tracking issue for work on v0.9.

[ripytide]

Okay, I've finished trawling through every issue both closed and open in the issue tracker and itemizing the actionable improvements I agree with in the tracking list above. Some improvements didn't yet have their own issues (particularly many of the points brought up in #39) so I opened some new ones for them. There were also some new improvements I came with, such as #65 and #66, not previously discussed as far as I am aware.

What do you think @kornelski? Specifically it would be useful to me if you'd state which of the listed improvements you'd accept or reject so I don't have to spend time implementing things you'd reject.

[kornelski]

Approvals

• Create a v0.9 branch #63
• as_mut_slice is confusing on Vec #14
• Colour constants and RGBW #21
• CamelCase for acronym typenames? #25
• How to name methods for integer type conversions? #46
• Change word component to subpixel. #65
• Switch to const generic arrays instead of slices. #66
• Fix BGR::new() argument ordering for v0.9 #67
• Allow docs.rs to auto-label optional features. #68
• Creation of a PixelExt trait for all non-fundamental trait methods. #69
• Remove the ComponentBytes and AsPixels traits #70
• Move all items to the top-level. #72
• Remove feature flags for extra types #73

[ripytide]

I've decided that I'll be shifting my focus from working on a 0.9 of this crate to creating a new crate due to the decision that this crate will not making any semver-trick incompatible changes. See #83 and #84 for more discussion on this issue.

I'll leave this tracking issue open in case anyone else wants to pickup where I left off.

[ripytide]

After more discussion in #85 I am now happy to continue development on v0.9, I did make a crate called pixeli but I'll deprecate that now for this crate.

[kornelski]

Great. Thanks.

[kornelski]

• Bring back fn new() for sensible-order RGB types. The type literal requires a lot of shift-pressing. Maybe fn new_bgr(b,g,r) too?
• Aliases for RGB8/RGB16. Type hints are repetitive, and other forms require turbofish.
• Convenience methods for bytemuck? slice.as_rgba() vs bytemuck::cast_slice::<Rgba<u8>>(slice).
• Add prelude::*? There's a bunch of traits.

[ripytide]

I'm not sure if this issue is useful anymore

[rursprung]

@ripytide & @kornelski: is there any news on the upcoming v0.9? this issue is closed but it hasn't been released yet
also: is there a description of the gap between v0.9 and an upcoming v1.0 (i.e.: why is this still 0.x / what's missing for 1.0?)

thanks for all your work on this so far!

[ripytide]

@rursprung long time no see!

See #131 and the README.md for our most up to date plan. But in short I think we are waiting to release v0.8.90 which has all the new stuff to allow people to try out the alphas of that version to gather feedback.

For example, about a month ago I attempted to integrate the new version of rgb into a project I'm working on and in the process found some issues that bothered me: #136 #135. Since such changes are infinitely harder to make after making a full release I think it is worth taking the time now to get things sorted.

Perhaps a good metric would be no breaking changes made in 3 months?