Node release catch-up plan #277
Comments
|
|
|
|
|
|
Just tried to work through this but I am getting a segfault... |
|
There are compilation failures when building |
|
There are compilation failures when building |
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 ran 2 skips, no failures |
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 🎊 but will let it live in the repo for a few days prior to cutting a release |
|
Be aware that #271 merged set the version to 0.6.5, not to 0.7.0 as suggested above, see 7193406#diff-57c74f5bd99f4a8425e28b076319f9935cd46a3b2bcfa6d6ccceddd651f2ce6fR4. |
|
Good catch @tisba! @SamSaffron I'll cut:
|
|
I have created 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 |
|
|
(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).
minimal.rb# frozen_string_literal: true
# Run with:
# ruby minimal.rb
# -or via docker-
# docker run -it --rm -v "$(pwd)":/app -w /app ruby:3.2.2 ruby /app/minimal.rb
require "bundler/inline"
gemfile do
source "https://rubygems.org"
gem "mini_racer", github: "rubyjs/mini_racer", branch: "stable-0.7"
end
require "libv8-node"
require "rbconfig"
puts "RbConfig::CONFIG['LIBS']: #{RbConfig::CONFIG["LIBS"]}"
puts "RUBY_VERSION : #{RUBY_VERSION}"
puts "RUBY_PLATFORM: #{RUBY_PLATFORM}"
puts "MiniRacer::VERSION: #{MiniRacer::VERSION}"
puts "MiniRacer::LIBV8_NODE_VERSION: #{MiniRacer::LIBV8_NODE_VERSION}"
puts "Libv8::Node::VERSION: #{Libv8::Node::VERSION}"
puts "Libv8::Node::NODE_VERSION: #{Libv8::Node::NODE_VERSION}"
puts "Libv8::Node::LIBV8_VERSION: #{Libv8::Node::LIBV8_VERSION}"
ctx = MiniRacer::Context.new
puts ctx.eval("1+1") |
the idea is to release:
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 |
|
Yay... got releases out for 0.7.0 and 0.8.0 this morning 🎊 thanks heaps! |
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 #283 and #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? |
|
#288 is not explicitly related to 19.x+ support, by the way -- the issue occurs in all versions. |
|
Thanks @Fayti1703 I confused it with this one: #283 (comment)
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. |
I don't think 0.8.1 is needed anymore as we jumped straight to node 18.16 on 0.8.0 via 0978356
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 #283 (comment) 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 #284 |
|
Reading the initial description… it looks like we basically did Step 8
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. |
Yeah @SamSaffron elected to release as 0.9.0.
Possibly:
We'll see. It always was an optional step in the original plan.
Yeah, not really a problem, e.g once 20 is fixed the |
|
In any case, to keep things up to date I've built and pushed: And updated #284 to use that. |
|
On a whim I expended a few CPU cycles and pushed: Guess what, #299 has all but one innocuous† test passing, no snapshot crash.
@tisba I'm going to take you up to your words, can you test that † This is the same as #284 (comment) which might actually be a correct |
|
My updated core plan:
And stretch goals:
Rationale for the intermediate bumps and merges is to have valid branching points for stable branches should we elect to release |
|
wow this is fantastic news, thanks @lloeki |
|
This is awesome news! 🚀
I can take some time in the next days to test things more thoroughly, but mini_racer from c30ec4d with Update Same (☝️) on Update 2 I did various simple sanity checks based on the same commit (☝️), all on |
|
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. |
|
|
|
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, |
|
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.0and16.19.0.0were built and pushed for all gem platforms for testing purposesnode-16,node-17, andnode-18branchesmini_racermini_racercode changes. PRs are open on #271 and #261mini_racerwithnode-17so as not to block these users.aarch64-linux-muslcross-compiling on CI is currently disabled due to some brokennessProposed plan
(1) build
node-16,node-17, andnode-18current 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.117.9.1.118.13.0.1This fixes those broken versions WRT the locale bug, and moves us closer to the "up-to-date goal" with builds we know are working.
(2) bump
mini_racerdependency requirement to~> 16.19.0.0and release mini_racer0.6.4This allows every user of current
mini_racerto immediately move to a Node safer than 16.10.0 (and safest, short for one version)(3) Merge #271 and release
mini_racer0.7.0.This allows every user of
mini_racerto move to the latest node 17 even for OSes not supported by node 18.(4) Merge #261 and release
mini_racer0.8.0.This allows every user of
mini_racerthat can to quickly move to node 18 without us being blocked by potential breakage coming from 18.13.0 -> 18.16.0(5) Bump
node-16branch to16.20.0.0,node-18branch to18.16.0.0.16.20.0.018.16.0.0(6) Bump
mini_racerdependency requirement to~> 16.20.0.0and release mini_racer0.6.5This 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.
(7) There is no more Node 17 release, so nothing more to do here.
(8) Bump
mini_racerdependency requirement to~> 18.16.0.0and releasemini_racer0.8.1.This should be the safest release for Node 18, but may not support some older OSes or compilers.
(9) Create
node-19branch 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_racerdependency requirement to~> 19.9.0.0and releasemini_racer0.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.
(11) Create
node-20branch 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_racerdependency requirement to~> 20.2.0.0and releasemini_racer0.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.
The text was updated successfully, but these errors were encountered: