Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release version 0.22 #973

Merged
merged 42 commits into from Jul 20, 2019
Merged

Release version 0.22 #973

merged 42 commits into from Jul 20, 2019

Conversation

HeroicKatora
Copy link
Member

@HeroicKatora HeroicKatora commented Jun 11, 2019

As discussed in #865 we're deferring the changes to ColorType onto another
branch and/or prerelease versions of the next api for now due to several other
API changes that await release. The same seems sensible for the error cleanup.
This is a huge merge commit to ensure we don't miss any changes that
happened in the version-0.21 branch.

This is also a call to suggest outstanding breaking changes that should be part
of 0.22, such as #901.

HeroicKatora and others added 30 commits April 13, 2019 10:12
Replaces image-rs#885, or rather was discovered during it as it was originally
trying to reason abouts its safety.
This just makes life easier.
The command used to rename is also added to the minimization script, to
avoid producing the same issue in future corpus directories and to have
a reference if necessary.
Most uncomplete matches are removed by creating proper enums in the webp
implementation and parsing to those constant variants early on. Some
unsupported operations are explicitely failed with a Unsupported error
variant.
Includes two seeds that were small enough to be viable. They are simply
converted (with imagemagick) samples from the tests/images/ directory.
This is good enough for the first few failures and panics. If you want a
larger corpus, you can put other images into the directory although
larger images can slow the fuzzer down without necessarily giving larger
coverage.
This seems to originate from one of the samples provided in the RFC,
specifically on page 23. A working version, that does the check for its
input length, can be found in the attached implementation in section 20.
This error is diagnosed as a FormatError.
A partition not containing as much data as claimed in the header is a
format error. While ignoring it at that moment will likely lead to some
later issues, it is better to check that the read has indeed taken
place.
HeroicKatora and others added 10 commits June 5, 2019 23:15
Simply do not refresh the cache state when bits are required during the
decoding process than can be read into the decoder. This strategy is
suggested in the reference implementation of the RFC.
At least one of the table entries can exceed the range of a signed
16-bit integer in an intermediate result. The reference implementation
used an `int` of unspecified width for this but this is wasteful in
terms of size of the table (albeit only slightly since the table is
small).
Some of the operations can overflow in i32, according to debug mode
builds. This is not intentional as the math is applied to conceptual
fixed point numbers.
@HeroicKatora
Copy link
Member Author

@fintelia I'm not sure what to do, I see no easy way to make this work. Together with png having been converted to edition 2018 already and getting some major fixes for depth < 8 right now, I think we might have reached a tipping point where the old compiler version support is no longer maintainable. I had previously justified it as not having too big consequences but that might no longer hold true.

Any ideas?

@fintelia
Copy link
Contributor

I'd be in favor of just bumping the minimum supported version whenever our dependencies do. Without ecosystem wide guidance, deciding when to bump is mostly guesswork anyways. The past comment about what version we'd have to advance to is gone (lost in the force push?) but if I recall correctly it was 1.26.1 which is just ever so slightly more than a year old. Supporting a year of past versions seems like a very reasonable policy

@HeroicKatora
Copy link
Member Author

The dependency of rayon is a year old now but it seems that rayon itself had not bumped version for that time. But the Rust version is even much older, true. I'm also more inclined to just bump version now instead of doing another 'major' release that bumps version later. Let's also not forget that we have the existing 0.21 release with all bugfix contained here (although we might want to update the .travis.yml on its branch to reflect the supported status) and this is mainly an interface change and adding new encoders.

@HeroicKatora
Copy link
Member Author

HeroicKatora commented Jun 19, 2019

Ok, then how to select the version to use and which version? At least the current requirement of all our fully updated dependencies but possibly more. Like edition = 2018.

@fintelia
Copy link
Contributor

I really don't have any ideas on how to pick a version, and I'm fine with pretty much anything at least a few releases ago. The first release with edition = 2018 seems like a totally defensible option though.

@HeroicKatora
Copy link
Member Author

The first release with edition = 2018 seems like a totally defensible option though.

Which would be 1.31.

@lovasoa
Copy link
Contributor

lovasoa commented Jul 5, 2019

Will the API change suggested in #901 be part of version 0.22 ?

@HeroicKatora
Copy link
Member Author

@lovasoa There are a few open points of discussion that have yet to be addressed. I'd personally be happy if they can be answered before the release (and included) but don't want to delay for too long.

@HeroicKatora
Copy link
Member Author

Debian Buster is scheduled to release as stable today and includes Rust 1.34.2. I suppose the alleviates some compatibility concerns. Is there any reason not to bump to that version instead of 1.31 now that bumping is necessary?

@martinlindhe
Copy link
Member

I support using 1.34.2 since its in debian stable starting today

@fintelia
Copy link
Contributor

fintelia commented Jul 7, 2019

That sounds good to me, although I don't think we should commit to always supporting the Rust version in Debian stable since that can potentially get to be several years old.

@HeroicKatora
Copy link
Member Author

HeroicKatora commented Jul 7, 2019

Ok, I've provided the bump in a seperate PR (#984) so that remaining tentative changes for the release (#980 and potentially resolution of #901) can be tested.

In particular also references the web page and blog.
@HeroicKatora HeroicKatora merged commit 9fc1f01 into image-rs:master Jul 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet