Version 1.0?

[cole-miller]

I'm using this crate for interoperability in the public interface of one of my projects (https://github.com/sndjvu/workspace), and I'd love to see a 1.0 release. Are there any issues blocking that, or breaking changes that need to be implemented? I'd be happy to contribute if I can.

[MaximilianKoestler]

I was thinking about using this crate in public interfaces as well (and there is a post discussing interoperability using the rgb crate as an example on users.rust-lang.org).

So I would also be really happy if this crate could be officially stabilized as 1.0 soonish.

[kornelski]

I'm planning to use https://github.com/dtolnay/semver-trick to re-export 0.8 types in 1.0 to make them compatible.

There are no blockers for 1.0, other than my indecision.

• is bytemuck the right crate for the "plain old data" trait? There are a few candidates. libstd may get one someday, maybe.

• what should be in traits vs inherent methods? Currently it's a bit of a mix.

• is naming ok? I think I'm generally happy with method names, but I don't particularly like trait names, and I'm not sure if traits are needed at all.

• Does alt module make sense? I should probably just dump all types at top of the crate, and add feature flags for them.

• I'm not sure if my assumptions about From are sensible. RGB8 -> RGB16 conversion could either be assumed as RGB<T> -> RGB<U> where U: From<T>, or a conversion that is t*65535/255. One is what you'd expect from Rust, the other is what you'd expect from RGB, and this crate is both.

[cole-miller]

Fwiw:

• I'd support moving everything in alt to the root. I don't know that feature flags are needed since the type names are all distinct, there are no new dependencies introduced, and (I assume) the impact on compilation time is negligible, but I don't have a problem with using them.
• I like the idea of a generic impl<T, U: From<T>> From<RGB<T>> for RGB<U>, combined with inherent methods to do the RGB-specific conversions from RGB8 to RGB16, etc.
• On the other points I don't have a strong opinion.

[kornelski]

I think I'm going to wait with 1.0, and release 0.9 with a focus on generic programming. Currently the crate lacks traits for properly abstracting over RGB and RGBA. Traits like ComponentMap can't skip alpha nicely.

So I'm thinking about redesigning all the traits.

• Leave byte casts to the bytemuck crate, which has to remain a dependency for the Pod trait.

• Move everything else to a single Pixel trait, and use that instead of inherent methods.

[rursprung]

I think I'm going to wait with 1.0

since it has been two years i wanted to check back with you if you see any chance of releasing v1.0.0 at some point? after all the rgb crate has over 9 million downloads and is heavily used in the rust ecosystem (see also the dependent crates - though that report seems to be broken at the moment for the rgb crate) and having a stable release would be beneficial for all of them.

do you have a roadmap to releasing a v1.0.0? it would be cool if you could create the tickets for what you think is missing for v1.0.0 and assign them to a v1.0.0 milestone.

rationale: theoretically, one should only build on released software, so using 0.x pre-releases for production software isn't looked on too well. in the rust eco-system there are sadly a lot of crates which stay on 0.x for years but are heavily used. having a roadmap helps in understanding why a crate is not yet released as 1.x (or higher) and allows analysing the trade-offs (is it acceptable to use the crate in production even though these features are missing?).

furthermore, this would help with contributors: they know where work still needs to be done and they can offer their help focused on these topics.

if you're worried about the major bump causing breaking changes for consumers you could release a last 0.8.x release afterwards which makes use of the semver trick to ensure compatibility (for the things where you don't do breaking changes between 0.8 and 1.0 anymore).

while my crate is only a super small fish in the pond (and my dependency to rgb is purely optional) i would prefer to only release a stable release of my crate once there's a stable release of rgb since it's part of my API.

[kornelski]

Yes, I'll be using the semver trick to keep compatibility with 0.8 where possible, and I'll have to focus on providing smooth upgrade path.