search

quickjs-ng / quickjs

QuickJS, the Next Generation: a mighty JavaScript engine
MIT License
691 stars 66 forks source link

Is there a timeline for the planned merge into quickjs? #374

Open ahaoboy opened 2 months ago

ahaoboy commented 2 months ago

Some projects considering the compatibility of quickjs-ng will face the implementation of the function after the quikcjs-ng merged into quickjs, due to quickjs-ng added a lot of functionality and header files have been changed a lot, need to do a lot of work in order to be compatible, so whether there is a clear merge into quickjs schedule? If there is a short term plan (maybe half a year?), I'd like to see it. then the adaptation work will be worthwhile.

saghul commented 2 months ago

We don't have a precise timeline, but there is willingness from both sides. You might have seen @chqrlie contributing to this repo, he is one of the original authors.

chqrlie commented 2 months ago

Hello, My plan is to converge by fall '24, so stay tuned. In any case, the APIs should be identical by then if not sooner. Best Chqrlie.

jamestiotio commented 2 months ago

Hi folks, just wanted to check. After the merging, which repository would be the canonical origin/upstream repository of quickjs? Would it be this repository or Bellard's mirror?

Thank you for all the work folks!

saghul commented 2 months ago

We haven't talked about that yet.

jamestiotio commented 2 months ago

Ah got it, thanks for the quick response! Will monitor this repository for future developments and updates then.

ahaoboy commented 2 months ago

Is it possible to create a todo list so that community members can also participate? Although it may not be possible to submit code directly, a large number of third-party libraries based on qjs need to be updated. Changes to qjs-ng header files and integrated patches may affect the upstream. I believe community members will want to provide some help We can even summarize the issues we had during the upgrade process, and give some documentation explaining the header changes and how to use the new api.

saghul commented 2 months ago

Not a bad idea!

We have tried, hard, not to change APIs just because, so unless you are using new APIs they should be source compatible.

I'll try to start a list of the differences.

coreybutler commented 3 weeks ago

It sounds like this effort is just getting underway (which is great). I'd like to encourage discussion about the versioning scheme that this will land on. I noticed this repo uses semantic versioning with project releases while the bellard mirror uses a calendar versioning approach with simple downloads.

This can impact community-driven tooling that starts to surface around this (like version managers & build tools).

My $0.02 (fwiw): I'd encourage the use of semver with project releases to align with how most other engines/runtimes handle releases.

chqrlie commented 3 weeks ago

@coreybutler I agree semantic versioning is preferable. Will work on converging that soon.