Closed lloeki closed 5 months ago
16.19.0.1
has been built locally for all gem platforms and pushed to rubygems
17.9.1.1
has been built locally for all gem platforms and pushed to rubygems
18.13.0.1
has been built locally for all gem platforms and pushed to rubygems
(2) bump mini_racer dependency requirement to ~> 16.19.0.0 and release mini_racer 0.6.4 bump release
This allows every user of current mini_racer to immediately move to a Node safer than 16.10.0 (and safest, short for one version)
Just tried to work through this but I am getting a segfault...
-- C level backtrace information -------------------------------------------
/home/sam/.rubies/ruby-3.2.1/bin/ruby(rb_print_backtrace+0x14) [0x5597194692fb] /home/sam/src/ruby-3.2.1/vm_dump.c:785
/home/sam/.rubies/ruby-3.2.1/bin/ruby(rb_vm_bugreport) /home/sam/src/ruby-3.2.1/vm_dump.c:1080
/home/sam/.rubies/ruby-3.2.1/bin/ruby(rb_bug_for_fatal_signal+0xe8) [0x55971953de58] /home/sam/src/ruby-3.2.1/error.c:813
/home/sam/.rubies/ruby-3.2.1/bin/ruby(sigsegv+0x4b) [0x5597193b56bb] /home/sam/src/ruby-3.2.1/signal.c:964
/usr/lib/libc.so.6(0x7f6691a46ab0) [0x7f6691a46ab0]
/home/sam/.rubies/ruby-3.2.1/bin/ruby(RVALUE_MARKED+0x9) [0x559719276d03] /home/sam/src/ruby-3.2.1/gc.c:1656
/home/sam/.rubies/ruby-3.2.1/bin/ruby(gc_mark_set) /home/sam/src/ruby-3.2.1/gc.c:6930
/home/sam/.rubies/ruby-3.2.1/bin/ruby(gc_mark_ptr) /home/sam/src/ruby-3.2.1/gc.c:7044
/home/sam/.rubies/ruby-3.2.1/bin/ruby(rb_mark_end_proc+0x19) [0x559719255919] /home/sam/src/ruby-3.2.1/eval_jump.c:84
/home/sam/.rubies/ruby-3.2.1/bin/ruby(gc_mark_roots+0x3ed) [0x559719277efd] /home/sam/src/ruby-3.2.1/gc.c:7562
/home/sam/.rubies/ruby-3.2.1/bin/ruby(gc_marks+0x40d) [0x55971927af8d] /home/sam/src/ruby-3.2.1/gc.c:8244
/home/sam/.rubies/ruby-3.2.1/bin/ruby(gc_start) /home/sam/src/ruby-3.2.1/gc.c:9547
/home/sam/.rubies/ruby-3.2.1/bin/ruby(heap_prepare+0x22) [0x55971927ea0a] /home/sam/src/ruby-3.2.1/gc.c:2431
/home/sam/.rubies/ruby-3.2.1/bin/ruby(heap_next_free_page) /home/sam/src/ruby-3.2.1/gc.c:2672
/home/sam/.rubies/ruby-3.2.1/bin/ruby(newobj_alloc) /home/sam/src/ruby-3.2.1/gc.c:2780
/home/sam/.rubies/ruby-3.2.1/bin/ruby(newobj_of0+0x56) [0x55971927f669] /home/sam/src/ruby-3.2.1/gc.c:2876
/home/sam/.rubies/ruby-3.2.1/bin/ruby(newobj_of) /home/sam/src/ruby-3.2.1/gc.c:2896
/home/sam/.rubies/ruby-3.2.1/bin/ruby(rb_wb_protected_newobj_of) /home/sam/src/ruby-3.2.1/gc.c:2918
19.9.0.0
has been built locally for all gem platforms and pushed to rubygems.
There are compilation failures when building mini_racer
against it though.
20.2.0.0
has been built locally for all gem platforms and pushed to rubygems.
There are compilation failures when building mini_racer
against it though.
Just tried to work through this but I am getting a segfault...
Strange, all tests were green before I pushed.
@SamSaffron Let's track it in a separate issue to keep this one focused on global progress
@seanmakesgames would you like to test these gems out?
Yeah--
Yesterday middle of day filled up very quickly. Catching up now.
on mini_racer/master, updated LIBV8_NODE_VERSION = "~> 16.19.0.0"
ran bundle
, ran rake clean compile test
2 skips, no failures
@SamSaffron
Just tried to work through this but I am getting a segfault...
What platform are you on for this one?
Oh sorry about this... was a brainfart ... I forgot to clean ... all is good and new version is out
Updated @lloeki checklist!
also merged in 17 :confetti_ball: but will let it live in the repo for a few days prior to cutting a release
Be aware that https://github.com/rubyjs/mini_racer/pull/271 merged set the version to 0.6.5, not to 0.7.0 as suggested above, see https://github.com/rubyjs/mini_racer/commit/7193406ff134e57e141eca5f042600d92edcd583#diff-57c74f5bd99f4a8425e28b076319f9935cd46a3b2bcfa6d6ccceddd651f2ce6fR4.
Good catch @tisba!
@SamSaffron I'll cut:
stable-0.6
branch)stable-0.7
branchI have created stable-0.6
and stable-0.7
, from which we'll be able to maintain and release older versions non-linearly (which is the case here).
Not that we usually should with any regularity, but having that mobility clearly defined is nice instead of comping up with ad-hoc solutions on the spot, especially when one has to do an emergency release. Also ties in with #276 as we should have a clearly delineated, written down support policy.
Another good side effect of these is that they can be referenced as is in libv8-node
for running testing against mini_racer
on the various node-XY
branches.
(will update this with further tests)
I'm going to test all supported Ruby verstions at their latest patch level (3.0.6, 3.1.4 and 3.2.2 currently) on M1 and x86 native on Ventura 13.4, as well as on aarch64-linux and x86-linux using Docker. For testing I'm using a minimal test (see below). For Ruby 3.2.2 I can run a more comprehensive product test suite (proprietary though).
RUBY_VERSION |
RUBY_PLATFORM |
branch | minimal.rb | proprietary |
---|---|---|---|---|
3.0.6 | arm64-darwin22 | stable-0.6 (16b521d) | ✅ | |
3.1.4 | arm64-darwin22 | stable-0.6 (16b521d) | ✅ | |
3.2.2 | arm64-darwin22 | stable-0.6 (16b521d) | ✅ | ✅ |
3.0.6 | x86_64-darwin22 | stable-0.6 (16b521d) | ✅ | |
3.1.4 | x86_64-darwin22 | stable-0.6 (16b521d) | ✅ | |
3.2.2 | x86_64-darwin22 | stable-0.6 (16b521d) | ✅ | ✅ |
3.0.6 | aarch64-linux | stable-0.6 (16b521d) | ✅ | |
3.1.4 | aarch64-linux | stable-0.6 (16b521d) | ✅ | |
3.2.2 | aarch64-linux | stable-0.6 (16b521d) | ✅ | ✅ |
3.0.6 | arm64-darwin22 | stable-0.7 (c0a6a34) | ✅ | |
3.1.4 | arm64-darwin22 | stable-0.7 (c0a6a34) | ✅ | |
3.2.2 | arm64-darwin22 | stable-0.7 (c0a6a34) | ✅ | ✅ |
3.0.6 | x86_64-linux | stable-0.6 (16b521d) | ✅ | |
3.1.4 | x86_64-linux | stable-0.6 (16b521d) | ✅ | |
3.2.2 | x86_64-linux | stable-0.6 (16b521d) | ✅ | ✅ |
3.0.6 | aarch64-linux | stable-0.7 (c0a6a34) | ✅ | |
3.1.4 | aarch64-linux | stable-0.7 (c0a6a34) | ✅ | |
3.2.2 | aarch64-linux | stable-0.7 (c0a6a34) | ✅ | ✅ |
3.0.6 | arm64-darwin22 | 0.8.0 | ✅ | |
3.1.4 | arm64-darwin22 | 0.8.0 | ✅ | |
3.2.2 | arm64-darwin22 | 0.8.0 | ✅ | ✅ |
3.0.6 | x86_64-darwin22 | 0.8.0 | ✅ | |
3.1.4 | x86_64-darwin22 | 0.8.0 | ✅ | |
3.2.2 | x86_64-darwin22 | 0.8.0 | ✅ | |
3.0.6 | aarch64-linux | 0.8.0 | ✅ | |
3.1.4 | aarch64-linux | 0.8.0 | ✅ | |
3.2.2 | aarch64-linux | 0.8.0 | ✅ | ✅ |
3.0.6 | arm64-darwin22 | 0.8.0 | ✅ | |
3.1.4 | arm64-darwin22 | 0.8.0 | ✅ | |
3.2.2 | x86_64-linux | 0.8.0 | ✅ | ✅ |
master
since we have stable-0.7
from which to release 0.7.0
targeting node 17stable-0.8
, which doubly makes sense since it's LTS nowmaster
now tracks "future" work:
libv8-node-19
and opened #283 as draft to target node 19.9.0master
it should give birth to branch stable-0.9
libv8-node-20
and opened draft #284 as draft to target node 20.x (currently 20.2.0)libv8-node-19
as base: once libv8-node-19
is merged it will automatically use master
as basethe idea is to release:
0.6.5
from stable-0.6
to get mini_racer to use the very latest node 16 (which is actually much more recent than node 17)0.7.0
from stable-0.7
to get mini_racer to use node 17.9.10.8.0
from stable-0.8
to get mini_racer to use node 18.16.0 (we can probably skip 18.13.0)then work on node 19, which should trickle down to making node 20 mostly (hopefully completely) work.
Thanks @tisba for that testing, you can probably try branch stable-0.8
as well
Yay... got releases out for 0.7.0 and 0.8.0 this morning :confetti_ball: thanks heaps!
Thanks @tisba for that testing, you can probably try branch
stable-0.8
as well
Will try to put the released 0.8.0 through CI tomorrow. My "minimal" test seems fine.
Just tested 0.8.0 (see updated table above) and it looks all good.
Almost a little bit too smooth so far 😁
Looks like we're kind of stuck with our plan. Not sure what prevents us from step 8 (releasing 0.8.1) or why we need this step, but looking at https://github.com/rubyjs/mini_racer/pull/283 and https://github.com/rubyjs/mini_racer/issues/288 it looks like getting Node 19.x+ support will be a challenge.
Is there anything we can do in general so that we're not getting stuck (again) for a long time?
Thanks @Fayti1703 I confused it with this one: https://github.com/rubyjs/mini_racer/pull/283#issuecomment-1572735274
the issue occurs in all versions.
That may sound strange but if it's already there in a released version, I'm on the opinion that it should not be a blocker for a new release based on 19 or 20 (provided we fix new blockers). Of course we should ultimately find a way to fix it but I'd rather make sure we're catching up with the train.
Not sure what prevents us from step 8 (releasing 0.8.1) or why we need this step
I don't think 0.8.1 is needed anymore as we jumped straight to node 18.16 on 0.8.0 via https://github.com/rubyjs/mini_racer/pull/261/commits/09783566c89bd1e68d65d4d301002441455df233
Looks like we're kind of stuck with our plan
Yeah that's basically in line with what I expected, and 19 is actually even more challenging than I anticipated. At least it's a stable target since it won't move anymore, and it should cover most of the ground towards 20 (well, except if https://github.com/rubyjs/mini_racer/pull/283#issuecomment-1585816428 is a node 19 bug fixed in node 20).
Nothing very effective comes to mind on the general front, the only way forward seems to be through it and get these crashers sorted out. FYI I'm booked for a couple of weeks while we kick off the quarter, then I can carve some time out to try to give @Fayti1703 a hand.
I moved to try things on node 20 https://github.com/rubyjs/mini_racer/pull/284
Reading the initial description… it looks like we basically did Step 8
8) Bump mini_racer dependency requirement to ~> 18.16.0.0 and release mini_racer 0.8.1.
Only it has been released as 0.9.0, but 🤷 The 0.8.1 release works fine in my testing and we already adopted it to prod in my day job.
I moved to try things on node 20 #284
Just curious: Are you planning to skip V8 19 altogether, @lloeki? AFAIK #284 is still based on the [libv8-node-19](https://github.com/rubyjs/mini_racer/tree/libv8-node-19)
branch.
In any case, let me know if I can help in any way like with testing things.
it has been released as 0.9.0
Yeah @SamSaffron elected to release as 0.9.0.
Are you planning to skip V8 19 altogether
Possibly:
We'll see. It always was an optional step in the original plan.
is still based on the
libv8-node-19
Yeah, not really a problem, e.g once 20 is fixed the libv8-node-20
PR could be merged to master
instead (which would include the libv8-node-19
contents as historical transition) and the libv8-node-19
PR closed, or we could merge libv8-node-19
then libv8-node-20
(which would have its base automatically changed to master
). Whatever works, but we're not there yet.
In any case, to keep things up to date I've built and pushed:
libv8-node-20.12.1.0-aarch64-linux-musl.gem
libv8-node-20.12.1.0-aarch64-linux.gem
libv8-node-20.12.1.0-arm64-darwin.gem
libv8-node-20.12.1.0-x86_64-darwin.gem
libv8-node-20.12.1.0-x86_64-linux-musl.gem
libv8-node-20.12.1.0-x86_64-linux.gem
libv8-node-20.12.1.0.gem
And updated https://github.com/rubyjs/mini_racer/pull/284 to use that.
On a whim I expended a few CPU cycles and pushed:
libv8-node-21.7.2.0-aarch64-linux-musl.gem
libv8-node-21.7.2.0-aarch64-linux.gem
libv8-node-21.7.2.0-arm64-darwin.gem
libv8-node-21.7.2.0-x86_64-darwin.gem
libv8-node-21.7.2.0-x86_64-linux-musl.gem
libv8-node-21.7.2.0-x86_64-linux.gem
libv8-node-21.7.2.0.gem
Guess what, https://github.com/rubyjs/mini_racer/pull/299 has all but one innocuous† test passing, no snapshot crash.
let me know if I can help in any way like with testing things.
@tisba I'm going to take you up to your words, can you test that libv8-node-21
branch?
† This is the same as https://github.com/rubyjs/mini_racer/pull/284#discussion_r1553476995 which might actually be a correct 0
value tripping an incorrect > 0
test.
My updated core plan:
MiniRacerTest#test_estimated_size
having total_heap_size_executable
be 0
is a valid resultMiniRacerTest#test_estimated_size
having total_heap_size_executable
> 0
stable-0.9
based on current main
libv8-node-19
libv8-node-19
to main
"as is"stable-0.10
at that merge commitlibv8-node-20
libv8-node-20
to main
"as is"stable-0.11
at that merge commitlibv8-node-21
libv8-node-21
to main
mini_racer
0.12.0And stretch goals:
stable-0.11
, and release 0.11.0stable-0.10
, and release 0.10.0Rationale for the intermediate bumps and merges is to have valid branching points for stable branches should we elect to release mini_racer
from these stable-*
branches based on these versions. Notably a version based on node 20 has merits because it's LTS.
wow this is fantastic news, thanks @lloeki
This is awesome news! 🚀
@tisba I'm going to take you up to your words, can you test that
libv8-node-21
branch?
I can take some time in the next days to test things more thoroughly, but mini_racer from c30ec4dec3e9c2146effb740aacba6c8f98f23aa with libv8-node
(21.7.2.0) looked already pretty good in my projects test suite (RUBY_PLATFORM: aarch64-linux, RUBY_VERSION : 3.3.0, Libv8::Node::VERSION: 21.7.2.0, Libv8::Node::LIBV8_VERSION: 11.8.172.17).
Update Same (☝️) on x86_64-linux
✅
Update 2 I did various simple sanity checks based on the same commit (☝️), all on arm64-darwin23
(macOS 14.4.1 (23E224)). Every currently non-EOL'd Ruby look fine: 3.1.4, 3.2.3 and 3.3.0 ✅
Shoot! We are so behind, we can't help test really. We have to update our ruby version and esprima first. Super pumped we're making some headway here though! Will help where we can.
Post your calls for support and we'll try!
Thanks a lot folks! I'll proceed with the plan as time permits.
total_heap_size_executable
being 0
is legit, so I fixed the test to have V8 JIT stuff, sort of making sure it's > 0
: https://github.com/rubyjs/mini_racer/commit/3754b179f9e86872a3f6bff0ecc3abe51d670474
Waiting for CI, then I'll finally pull the trigger on 0.12.0, and then, upstream Node.js 21.7.3.0 having been released a dozen days ago, mini_racer
will be the closest to "up to date" it has ever been since years.
And it's released.
Since we have caught up I'm closing this issue.
Stretch goals may or may not be attempted depending on whether there's any demand, in which case they should be tracked in their own issue.
Current status
18.13.0.0
and16.19.0.0
were built and pushed for all gem platforms for testing purposesnode-16
,node-17
, andnode-18
branchesmini_racer
mini_racer
code changes. PRs are open on #271 and #261mini_racer
withnode-17
so as not to block these users.aarch64-linux-musl
cross-compiling on CI is currently disabled due to some brokennessProposed plan
[x] (1) build
node-16
,node-17
, andnode-18
current branch tips locally, and publish the resulting gems to rubygems as16.19.0.1
,17.9.1.1
, and18.13.0.1
.16.19.0.1
17.9.1.1
18.13.0.1
This fixes those broken versions WRT the locale bug, and moves us closer to the "up-to-date goal" with builds we know are working.
[x] (2) bump
mini_racer
dependency requirement to~> 16.19.0.0
and release mini_racer0.6.4
This allows every user of current
mini_racer
to immediately move to a Node safer than 16.10.0 (and safest, short for one version)[x] (3) Merge #271 and release
mini_racer
0.7.0
.This allows every user of
mini_racer
to move to the latest node 17 even for OSes not supported by node 18.[x] (4) Merge #261 and release
mini_racer
0.8.0
.This allows every user of
mini_racer
that can to quickly move to node 18 without us being blocked by potential breakage coming from 18.13.0 -> 18.16.0[x] (5) Bump
node-16
branch to16.20.0.0
,node-18
branch to18.16.0.0
.16.20.0.0
18.16.0.0
[x] (6) Bump
mini_racer
dependency requirement to~> 16.20.0.0
and release mini_racer0.6.5
This should be the safest release for Node 16, applying to all users that can't or do not desire to move to a more recent major version.
[x] (7) There is no more Node 17 release, so nothing more to do here.
[ ] (8) Bump
mini_racer
dependency requirement to~> 18.16.0.0
and releasemini_racer
0.8.1
.This should be the safest release for Node 18, but may not support some older OSes or compilers.
[x] (9) Create
node-19
branch fromnode-18
, attempt build of Node19.9.0
, push once it builds, create issue if it doesn'tThis should handle most of the gnarliness towards Node 20. To be tracked more deeply in a separate issue.
[ ] (10) Bump
mini_racer
dependency requirement to~> 19.9.0.0
and releasemini_racer
0.9.0
.An optional step, but one that could make sense depending on Node 20 changes. At least internally it does make sense to proceed with this iterative step.
[x] (11) Create
node-20
branch fromnode-19
, attempt build of Node20.2.0
, push once it builds, create issue if it doesn'tThis may have additional changes compared to Node 19 but should be smaller. To be tracked more deeply in a separate issue.
[ ] (12) Bump
mini_racer
dependency requirement to~> 20.2.0.0
and releasemini_racer
0.10.0
.An optional step, but one that could make sense depending on Node 20 changes. At least internally it does make sense to proceed with this iterative step.
Each intermediate version reduces risk towards a final release and provides a fallback spot to have an actual release with the widest OS and compiler support.