search

kornelski / rust-rgb

struct RGB for sharing pixels between crates
https://lib.rs/rgb
MIT License
98 stars 19 forks source link

Version 1.0? #39

Open cole-miller opened 3 years ago

cole-miller commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.

cole-miller commented 3 years ago

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 commented 3 years ago

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 commented 10 months ago

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 commented 9 months ago

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.