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

2.0 Beta release checklist items #5635

Open
17 tasks
Manishearth opened this issue Oct 1, 2024 · 0 comments
Open
17 tasks

2.0 Beta release checklist items #5635

Manishearth opened this issue Oct 1, 2024 · 0 comments

Comments

@Manishearth
Copy link
Member

These are all the items from the release checklist and the graduation checklist that I think matter for ICU4X 2.0 beta in a way that cannot be resolved day-of release:

  • The crate should be almost fully documented
    • Almost every exported function should have docs coverage
    • There should be a crate-level example that illustrates a common use case for the component with the heading # Examples
    • All options and conditional code paths should have a corresponding docs test with the heading # Examples
  • The data structs should fully follow ZeroVec style
    • Deserialization should not have a "zero-copy violation" in the make-testdata test
    • Constructors should avoid allocating memory in the common case
    • Opaque blobs of data should be avoided if possible (instead use VarZeroVec, ZeroMap, etc.)
    • Data structs should not be panicky to load/deserialize and conform to data_safety.md
    • If any data structs use a large or unbounded number of data marker attributes, they are implemented in a way that reduces stack space, file size, and construction time, such as by having only a single variable-length field
  • The component should encourage i18n best practices
    • The component should produce correct results in all locales as generated by icu4x-datagen
    • Where applicable, the component should be consistent with ECMA-402 and UTS#35
    • Any gaps in i18n quality should be fixed, or, if that is not possible, they should have tracking issues and a concrete, resourced path forward. The intent is to not ship components with known i18n correctness problems and no plan to fix them in an upcoming release
    • The API design should be informally reviewed by someone else, who may be an ICU4X team member
  • There should be a completed changelog
  • We should go through ffi/capi/tests/missing_apis.txt and make note of glaring gaps, and ensure there is a clear path to filling them before the release.

These items need not be completed perfectly, as long as they are completed to some extent.

cc @sffc @robertbastian

@Manishearth Manishearth added this to the ICU4X 2.0 Beta ⟨P1⟩ milestone Oct 1, 2024
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

No branches or pull requests

1 participant