Open ripytide opened 3 weeks ago
Originally I was thinking about having 0.9 import 0.8 for compatibility, which would give 0.9 alpha releases back-compat.
But with the semver trick used in the other direction, it may make more sense to start with v0.8.999-alpha
, so that it can be tested including interaction with 0.8 crates.
Interesting, so you mean releasing the current 0.9
branch as a v0.8.999-alpha
release since it is non-breaking and so removing the need for a 0.9
release, except for when removing the legacy stuff?
Yes, the current 0.9 needs to be released as 0.8-something to be interoperable with the other 0.8 crates. 0.9 with legacy
turned on only has source code compatibility, but not backwards-compatible types across crates.
Sounds good. That would also let us deprecate the legacy stuff gently over a long period of time to encourage users to switch over to the new traits and other stuff.
A massive disappointment: Cargo won't unify v0.8.44
with v0.8.90-alpha.1
. Not even when requiring rgb = ">0.7,<0.9"
.
This complicates testing a lot.
I've run out of things on my personal checklist and I don't think any of the repo's remaining open issues are actionable for
v0.9
either:9 i don't really understand
25 is now fixed in v0.9
36 and #52 seem best left to users to implement themselves
39 and #64 are meta-issues
46 seems best left to another crate dedicated to pixel conversions as we have discussed in https://github.com/image-rs/canvas/issues/57 which I'm thinking of starting work on after finishing this crate's next release
Therefore, may I suggest (unless you have any outstanding issues/changes?) that now is the time to publish a
v0.9-alpha.1
? After the alpha release is out we can start validating the alpha release by migrating some crates currently depending onv0.8
. If all goes well then we could proceed with the full release + the semver-trickv0.8
, if issues are found then we can fix the issues, release another alpha release and repeat the cycle as many times as necessary. How does that sound?