Path to 1.0

[foresterre]

checklist for stabilization

Potential concerns per API level

High level
The queue is managed

• (HL1, #?) Should we rescale the queue for each element, or perhaps resize it by powers of two (how would we do the prediction)? (This would not necessary change the API, thus could be a determined after a stable release)
• ...

Low level
You are able to manage the queue yourself

• Should we add manual queue management API's before 1.0? Add / investigate manual buffer (queue) management API #51
• ...

library management

Questions

• (Q1) Are we happy with the current API? Do we expect breaking changes? Do, and if so, what do we like to add? yes
• (Q2) Is the terminology consistent?, after Improve the rustdoc documentation #54, yes
• (Q3) Is everything properly tested?, To the best of my knowledge, yes. We could add fuzzing, but we keep that as a wishlist item.
• (Q4) Is the documentation up-to-date? , after Improve the rustdoc documentation #54, yes
• (Q5) Are there performance considerations which should be handled before stabilizing the API? (benchmark)
  • According to my first preliminary benchmarks, smallvec may not be a good fit as the default feature. I'm not sure if my benchmark is actually performed correctly, but disabling smallvec by default and keeping it as an option sounds like a safe choice.
  • This could be caused by having a too large stack size for smallvec; the docs recommend a small amount, an give 4 and 8 as example values. I'm not sure how small the amount should be.
  • Disabled by default in Disable smallvec by default #58, opt-in with --feature smallvec

List of actions

• (A1, automate publishing to crates.io #44) automated releases, This will be a task for after 1.0, after I completed the tooling required for https://github.com/foresterre/sic. The tooling will then be re-used by this project.

Planned time path

December 2020: Q1, Q5,
January 2021: Q2, Q3, Q4

1.0.0: February 2021

tagged open issues: M-v1.0.0