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.

Sign up for GitHub

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

Jump to bottom

We need a roadmap to 1.0.0 #12

Closed
foretspaisibles opened this issue Apr 20, 2015 · 35 comments
Closed

We need a roadmap to 1.0.0 #12

foretspaisibles opened this issue Apr 20, 2015 · 35 comments

Comments

@foretspaisibles
Copy link
Collaborator

Many of us would love to see a version 1.0.0 of Camomile! But how can we start to help if we do not have a roadmap? It would be great to prepare one!
@foretspaisibles
Copy link
Collaborator Author

Just a gentle ping on this! :)

@yoriyuki
Copy link
Owner

Cook it in the way as you like. For me, Camomile is dead. (Actually, OCaml is dead)

@foretspaisibles
Copy link
Collaborator Author

Wow, this is a statement! :)

Thank you a lot for the good work on Camomile!

Am I right thinking the various u* (ucorelib, etc.) libraries were meant to split Camomile in smaller libraries? Just out of curiosity, where are you looking at now? It looks like the OCaml community is thriving now, and definitely misses you! But anywhere you go, I wish you the best! :)

@youjinbou
Copy link

I don't know what makes you say that, but I feel that you're making a
mistake. Are you moving to a much more potent language? (I was thinking
Agda, Idris, ATS or even Coq). Anyway, I hope you'll find what you are
looking for.

On 10 August 2015 at 14:19, Yoriyuki Yamagata [email protected]
wrote:

Cook it in the way as you like. For me, Camomile is dead. (Actually, OCaml
is dead)

—
Reply to this email directly or view it on GitHub
#12 (comment).

@tategakibunko tategakibunko mentioned this issue Dec 4, 2015
Closed
@rgrinberg
Copy link
Collaborator

@yoriyuki sorry to hear about you and OCaml. I wish you the best.

Would you mind letting some users help out with maintenance on your projects then? For example, adding @michipili as a maintainer to Camomile? (Sorry for the nomination!)

@yoriyuki
Copy link
Owner

yoriyuki commented Dec 4, 2015

I added @michipili and you (@rgrinberg) to collaborators :-) If you need more setup (for example, creating a group), let me know.

@yoriyuki
Copy link
Owner

yoriyuki commented Dec 4, 2015

If other guys want to be collaborators, please let me know.

@foretspaisibles
Copy link
Collaborator Author

Thank you for doing this, @yoriyuki

@foretspaisibles
Copy link
Collaborator Author

@rgrinberg @tategakibunko I think it would be great to call the community to attention about the current state of Camomile and prepare together a roadmap for v1.0.0. I will prepare a backlog milestone and a few tickets to it, so that we can start discussing ideas.

If you (anybody) have any wish, please open tickets or start the discussion here. Thank you again @yoriyuki for the beautiful library you wrote!

@seliopou
Copy link
Collaborator

seliopou commented Dec 5, 2015

I'd like to help out as well. Could you add me as a collaborator?

@foretspaisibles
Copy link
Collaborator Author

Here is a short proposition for the next (pre 1.0.0) milestones:

  • v0.9.0 Modern build system, CI, opam pinning
  • v0.10.0 Remove dependencies, maybe rework interfaces, etc.

How does it sound?

@foretspaisibles foretspaisibles mentioned this issue Dec 5, 2015
Closed
@yoriyuki
Copy link
Owner

yoriyuki commented Dec 6, 2015

done. @seliopou

@yoriyuki
Copy link
Owner

yoriyuki commented Dec 7, 2015

What I thought for version 1.0.0 is, to support the recent Unicode version. The current Camomile only supports Unicode 3.2, which is ancient. A lot is changed from these days. As far as I know, to support the recent version, we need

  1. Update data file. I made uproplib, which is an interface to data files of Unicode version 7.0 (which, in turn, is based on Daniel Bünzli 's uucd) for this goal.
  2. Uppercase/Lowercase mapping. They added extra rules for ancient greek.
  3. Local data. Camomile uses ICU data, but now Unicode consortium published LDML (Locale Data Markup Language) repository. I think the syntax of collation rules did not change, but they are now embedded in an XML format.
  4. Unicode Collation algorithm. I did not check this yet. We need to look the change log of the technical report.
  5. Charmap files. I hope the format did not change, but probably we need to update the contents.

Just for suggestions.

@seliopou
Copy link
Collaborator

seliopou commented Dec 7, 2015

@yoriyuki thanks, these are great suggestions. I was poking around the ICU and CLDR and did notice that Camomile is way behind on the Unicode standard. You'll be happy to know, however, that CLDR produced an LDML to ICU converter, and ICU continues to ship the converted ICU files. I'm not sure which features these converted files will cover, but hopefully it won't be necessary to deal with XML within Camomile. If you know otherwise, it would be great to know.

@yoriyuki
Copy link
Owner

Do we have any timetable to 1.0.0? I'm still interested in supporting the newest version of Unicode, but it takes time (so we may aim it for 2.0.0).

@rgrinberg
Copy link
Collaborator

rgrinberg commented Aug 25, 2017 via email

@yoriyuki
Copy link
Owner

I post the issues which I think, are needed to solve to support the latest Unicode standard
#27 #28 #29 #30 #31

@yoriyuki
Copy link
Owner

yoriyuki commented Sep 7, 2017

Just for starting a discussion, I assigned several issues to the milestone v1.0.0

  • I don't label jbuilder migration because we already are working on it.
  • I don't label camlp4 removal neither, because we don't reach the consensus yet. We need actionable items for the milestone.

@yoriyuki
Copy link
Owner

I want to start working for the latest Unicode standard. But how we proceed? I will make a new branch for this purpose. Updating the latest standard would brake the library, even make it not compilable. Then, the final result would be completely different from the current one. If you change the main branch during this process, the change is difficult to port. What is the best practice for this kind of cases?

Another issue is: Should we create a branch for 1.0 or continue to develop on the main branch until 1.0 release?

I appreciate your input.

@rgrinberg
Copy link
Collaborator

rgrinberg commented Jan 23, 2018 via email

@yoriyuki
Copy link
Owner

I did three things:

  1. Make the master branch is protected. To change the master, you need to create a pull request and let someone review it.
  2. Create v1.0 branch. This branch is an integration branch for version 1.0 and also protected.
  3. Create Unicode10.0.0 branch. I will work for support of Unicode 10.0.0 using this branch. The branch is not protected.

@rgrinberg
Copy link
Collaborator

rgrinberg commented Jan 23, 2018 via email

@yoriyuki
Copy link
Owner

But I'm curious, why do we need a v1.0
integration branch for now? Seems like such a branch will be useful once
we have released 1.0, and are already working on your new branch in
master. In such a situation the integration branch would be useful to
make emergency bug fixes to 1.0. Or do you have another workflow in
mind?

Although I want API change minimal in 1.0 but there will be API change. If we develop 1.0 using the master, people using the master would be surprised. In particular, we do not have an backward compatible branch for v0.x.

My plan is once 1.0 is released, v1.0 is merged to the master and development of 1.x is continued on the master branch. In the same time, we make the integration branch v2.0 and start developing 2.0.

Sure, it is not the Git workflow but I feel reasonable. What do you think?

@rgrinberg
Copy link
Collaborator

Ah ok. Makes sense to me. Ok so we'll only be making fully backwards compatible changes to master. All api breaking changes for 1.0 will be kept in a branch.

Yeah, I think that's reasonable.

@yoriyuki
Copy link
Owner

I made some progress on #28

@yoriyuki
Copy link
Owner

yoriyuki commented Mar 21, 2018 •
edited
Loading

Another issue, which I always am worried about, is that Camomile is too large. Now UCD part taking almost 30Mbytes, we may need to do something for this. I'm always thinking about splitting Camomile into different packages so that a user can choose the level of functionalities.

For example,

  1. camomile-basic: basic data types like UTF-8 encoded strings, IO, some basic character encodings. Maybe monads and transducers etc. for convenience.
  2. camomile-algorithm: Unicode related algorithms like case mapping, collation, line breaking, etc.
  3. camomile-encodings: more esoteric character encodings.

Of course, there is another issue when we do it. Version 1.0 is a good occasion but it delays the release of version 1.0 further.

Might be a good idea to announce the existence of v1.0 branch.

@yoriyuki
Copy link
Owner

Anyways I made a group https://github.com/ocaml-camomile and 4 empty repositories.

@yoriyuki
Copy link
Owner

Started working on camomile-basic https://github.com/ocaml-camomile/camomile-basic It is already able to built.

@rgrinberg
Copy link
Collaborator

rgrinberg commented Mar 22, 2018 via email

@yoriyuki
Copy link
Owner

I see. Then we use the same repo. as now but split the opam package.

Since we have many tasks, we need to prioritize tasks.

  1. First prepare 1.0 quickly. I think we can merge your no dynamic configuration PR and update the contact address. (many files indicates the sourceforge address now.) Just one search/replace. I also want to unify Camomile's UChar and OCaml stlib's Uchar.
  2. Next, create v2.0 branch and split the package. Since this is a huge API change I think it is better to put them v2.0. Could you do an initial set-up? Then, I want to remove imperative Unicode strings (xString and ustring).
  3. Finally, support the recent Unicode standard for v3.0. As this is again a large change of behavior and APIs, it is better to make another major update.

@rgrinberg
Copy link
Collaborator

I think we can merge your no dynamic configuration PR and update the contact address

Sure. Also, saving it for post 1.0 is an option (up to you).

I also want to unify Camomile's UChar and OCaml stlib's Uchar.

I actually gave this a try already. This is also a breaking change unfortunately as stdlib's Uchar.t is more restrictive and doesn't allow any integer. From the docs:

(** The type for Unicode characters.

    A value of this type represents an Unicode
    {{:http://unicode.org/glossary/#unicode_scalar_value}scalar
    value} which is an integer in the ranges [0x0000]...[0xD7FF] or
    [0xE000]...[0x10FFFF]. *)

Camomile's Uchar is more permissive.

To clarify the branching situation:

  • master is where we do development of the upcoming version (1.0 as of now, 2.0 later, etc.)

  • After a release, we have a version specific where we backport bug fixes/improvements whenever possible.

@rgrinberg
Copy link
Collaborator

One more change I had in mind for 2.0 is the following use the Camomile module name for the library itself. Rather than using the more verbose CamomileLibrary. The Library suffix isn't really helpful.

@yoriyuki
Copy link
Owner

I think we can merge your no dynamic configuration PR and update the contact address

Sure. Also, saving it for post 1.0 is an option (up to you).

Done. It is inconsistent to what I said but doesn't matter much.

I also want to unify Camomile's UChar and OCaml stlib's Uchar.

I actually gave this a try already. This is also a breaking change unfortunately as stdlib's Uchar.t is more restrictive and doesn't allow any integer. From the docs:

(** The type for Unicode characters.

    A value of this type represents an Unicode
    {{:http://unicode.org/glossary/#unicode_scalar_value}scalar
    value} which is an integer in the ranges [0x0000]...[0xD7FF] or
    [0xE000]...[0x10FFFF]. *)
Camomile's Uchar is more permissive.

This restriction was implicit in Unicode Standard, and now it is explicit. So it's okay to (actually we should) restrict Unicode to this range. In particular, UChar with [0xD800] - [0xDFFF] code range brakes many algorithms.

To clarify the branching situation:
master is where we do development of the upcoming version (1.0 as of now, 2.0 later, etc.)
After a release, we have a version specific where we backport bug fixes/improvements whenever possible.

Sure. We need to do something about existing v1.0 branch but it is easy to deal with.

One more change I had in mind for 2.0 is the following use the Camomile module name for the library itself. Rather than using the more verbose CamomileLibrary. The Library suffix isn't really helpful.

Sure. I think v2.0 is a good opportunity to rearrange the module structure.

@yoriyuki
Copy link
Owner

I found migrating stdlib Uchar is not easy, because unidata contains non-scalar (out-of-range) code points. To fix this, we need to modify the large portion of the code. I think v3.0 when we support Unicode 10 is better opportunity.

So, I think now we are ready to release v1.0. Do you have anything left to do?

@yoriyuki
Copy link
Owner

Now we have 1.0.1. Continue to discuss on 2.0.0 at #70

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@seliopou @rgrinberg @youjinbou @yoriyuki @foretspaisibles