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

ICU4X 0.1 #204

Closed
zbraniecki opened this issue Aug 8, 2020 · 12 comments
Closed

ICU4X 0.1 #204

zbraniecki opened this issue Aug 8, 2020 · 12 comments
Assignees
Labels
C-process Component: Team processes T-task Type: Tracking thread for a non-code task
Milestone

Comments

@zbraniecki
Copy link
Member

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
Copy link
Member Author

zbraniecki commented Aug 8, 2020

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
Copy link
Member Author

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.

@zbraniecki zbraniecki added this to the ICU4X 0.1 milestone Aug 8, 2020
@sffc
Copy link
Member

sffc commented Aug 8, 2020

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
Copy link
Member Author

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
Copy link
Member

sffc commented Aug 9, 2020

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
Copy link
Member Author

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
Copy link
Member

sffc commented Aug 9, 2020

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.

@sffc sffc added the discuss Discuss at a future ICU4X-SC meeting label Aug 14, 2020
@filmil
Copy link
Contributor

filmil commented Aug 19, 2020

Looking at this now.

@filmil
Copy link
Contributor

filmil commented Aug 19, 2020

Seems reasonable to me.

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

@zbraniecki
Copy link
Member Author

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.

@sffc sffc removed the discuss Discuss at a future ICU4X-SC meeting label Aug 27, 2020
@sffc sffc added T-task Type: Tracking thread for a non-code task C-process Component: Team processes labels Sep 3, 2020
@sffc sffc added the discuss Discuss at a future ICU4X-SC meeting label Sep 11, 2020
@zbraniecki
Copy link
Member Author

zbraniecki commented Sep 11, 2020

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

@zbraniecki zbraniecki removed the discuss Discuss at a future ICU4X-SC meeting label Sep 17, 2020
@zbraniecki
Copy link
Member Author

ICU4X 0.1 released!

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-process Component: Team processes T-task Type: Tracking thread for a non-code task
Projects
None yet
Development

No branches or pull requests

3 participants