Is there a timeline for the planned merge into quickjs?

[ahaoboy]

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]

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]

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]

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]

We haven't talked about that yet.

[jamestiotio]

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

[ahaoboy]

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]

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]

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]

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

[p-bakker]

See #258 (reply in thread) for the latest on qjs vs. qjs-ng

Given that, this issue can likely be closed?