search

unicode-org / icu4x

Solving i18n for client-side and resource-constrained environments.
https://icu4x.unicode.org
Other
1.38k stars 176 forks source link

ICU4X 0.1 #204

Closed zbraniecki closed 4 years ago

zbraniecki commented 4 years ago

ICU4X is aiming to ship its first release of the meta-package at the end of Q3 or beginning of Q4.

The aim of the release is to collect the available subset of components backed by the DataProvider and release them to the community for evaluation and testing.

In this issue we'll discuss the expected scope of the release and considerations we want to take while preparing for it, and all issues and PRs aiming for 0.1 will be listed under the milestone - https://github.com/unicode-org/icu4x/milestone/5 .

zbraniecki commented 4 years ago

The aim of the initial release is to collect the first set of components backed by the DataProvider and release them to the public for evaluation and testing.

Release Driver: @zbraniecki Milestone

Based on the current velocity my hope is that by the EOQ we'll be able to ship:

Components:

The releases should work as stand-alone, and be available as icu and/or icu4x meta-crate for easy bundling.

Checklist:

zbraniecki commented 4 years ago

I'd like to suggest accumulating the checklist in this issue and starting a Wiki in this repo with the checklist and release plan there.

sffc commented 4 years ago

Thanks for writing this up!

Initial feedback on the checkboxes:

Data Provider, ICU4X bincode production and runtime: Maybe in another thread, I'd like to make this a little more specific. #200 introduces FsDataProvider, reading JSON from the filesystem, which is modular and easy to understand, but likely costs nontrivial code size and performance. I see a future StaticDataProvider as one that reads from bincode buffers loaded into static memory, likely with higher performance and smaller code size. So, in other words, I see this checkbox as less about bincode and more about a data provider reading from static data rather than the filesystem.

Data Provider, Async read: This is important, but I want to punt it to v0.2. We still have a lot of other even more fundamental problems to solve in the data provider space. I want to introduce an async DataProvider once we have robust code size and performance infrastructure.

UnicodeSet: I would love to see an "L3a" Unicode properties API powered by the data provider, time permitting. If Evan doesn't have enough time during the remainder of his internship, I'm willing to take a stab at this.

zbraniecki commented 4 years ago

Thank you!

So, in other words, I see this checkbox as less about bincode and more about a data provider reading from static data rather than the filesystem.

Maybe we should then separate those two? We can still serialize/deserialize ICU4X data to/from bincode, but separately we want to be able to read from static data.

This is important, but I want to punt it to v0.2.

Fair!

I would love to see an "L3a" Unicode properties API powered by the data provider, time permitting.

Added!

sffc commented 4 years ago

Maybe we should then separate those two? We can still serialize/deserialize ICU4X data to/from bincode, but separately we want to be able to read from static data.

Can you elaborate on what you envisioned when you wrote this bullet point?

zbraniecki commented 4 years ago

Can you elaborate on what you envisioned when you wrote this bullet point?

I think it would be useful to, in parallel to JSON, be able to produce bincode serialized files, store them, and load using DataProvider.

That is, according to what I understand from what you said, separate from loading static data into memory and then deserializing it using bincode.

If you don't think it is useful, I can remove it.

sffc commented 4 years ago

Ok, thanks for clarifying. Doing that piece should be a small PR based on #200. I'm not sure whether it's "hard enough" to rise to the level of a bullet point on the v0.1 checklist, but I don't feel strongly.

filmil commented 4 years ago

Looking at this now.

filmil commented 4 years ago

Seems reasonable to me.

One small request, would you be willing to let Locale implement ecma402_traits::Locale for the 0.1 release?

zbraniecki commented 4 years ago

One small request, would you be willing to let Locale implement ecma402_traits::Locale for the 0.1 release?

That's on the list as Components integrated into ECMA402 traits - my intention was to get Locale, PluralRules and a subset of DateTime to implement the traits.

zbraniecki commented 4 years ago

I updated the checklist, added 0.2 issue and wrote initial Release Process doc.

zbraniecki commented 4 years ago

ICU4X 0.1 released!

Thank you everyone! Onto the next milestone - https://github.com/unicode-org/icu4x/milestone/7 :)