Release 0.4

[nwin]

We should release a 0.3 when Rust 1.0 is released.

Since cargo is not able to read semver correctly (see rust-lang/cargo#952) we should just release a new 0.x every time we change the API in a incompatible way and add a new 0.x.y every time we make a patch.

[bvssvni]

In the other libs, I increment 0.x.y each time when making a change, to make it possible to track which version is on crates.io. Releases are pointing to a specific version to avoid breaking changes.

[ruuda]

The 0.x versions are initial development, so semver makes no compatibility guarantees:

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

For how long do we intend to stay in the 0.x regime? When do we call it 1.0?

[nwin]

Not before we have something that can nicely handle animated and progressive images. Dynamically typed images would also need some love. Should we keep Dynamic image or should we replace it by ImageBuffer? In the first case we would need at least 8 enum variants (RGB(A), Gray(A), 8 + 16 bits) but would still miss other color models. YBrCr?

I would not rush too much. Mozilla stayed 0.x for a long time as well.

[bvssvni]

We could do a stabilization process before 1.0 like Rust.

[ruuda]

Slightly off-topic, but regarding the colour models, I don’t think more enum variants for e.g. YCbCr are the way to go. They would encode the colour space in the type, but that is both not practical and limiting. There is no such thing as “an RGB image” (just like there is no such thing as “plain text”), colour information is always encoded in a colour space, and there are multiple ways of doing so. For example, there are sRGB and Adobe RGB colour spaces (and many more) that have red, green and blue channels, so having one RGB variant is misleading. It is much easier to be colour space agnostic and just have types for “three channels” or “one channel” (which makes Luma a bad name too, because it does not necessarily represent luma information), and have the user interpret the channels as a specific colour space. Even the notion of an alpha channel is not as simple as it may seem, other channels might be stored as premultiplied alpha or not. If you want to deal with colour spaces properly, then you need to go all the way. We could offer functions to convert between colour spaces (for example from sRGB to CIE 1931 or at least a linear colour space and back), so you can do proper resampling and other operations in a linear colour space, but the colour space need not be encoded in the type. In most cases I prefer more type safety, but in this case it would mean having an enum variant for every colour space that a user might possibly want to use, which is just not practical.

[nwin]

Sensible thoughts. I don't think this is off-topic. We should definitively get this straight before 1.0.

[nwin]

We could get some inspirations from http://gegl.org/babl/

[nwin]

Any objection that I just release 0.2? I don’t think that this cargo issue gets fixed anytime soon that it can’t parse the 0.2.0-alpha thing…

[bvssvni]

@nwin No problems.

[birktj]

This issue is both inactive and outdated so I will close it.