It sounds like there was at least some discussion of removing the hold on the nodejs packages from the install script, which it appears is still in there.
Anyway, my install is only ~4 months old, and after upgrading my home lab VM from Debian 12.13 to 12.14, I got:
The following packages have been kept back:
libnode-dev libnode108 nodejs
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
Is it considered only supported/best practice to leave the hold in place for these specific packages, or should it be removed? (I do understand why the freepbx17 and sangoma-pbx17 should not be touched)
Props for trying v17 on Debian 13; however, we are only supporting Debian 12. You’d have to wait for v18 on Debian 13 before Sangoma starts offering support.
That said, the entire NodeJS update situation is still an area that needs more work. The more testing and reports back from the research frontier you are on the better!
Oh shoot. I was so wrapped up in doing my Linux update testing for the week I confused versions when making the topic. My fault. This was 12.13 to 12.14 on the freepbx install.
Updated the title/topic to reflect the correct Debian versions. I take it your response still applies and I should leave the holds alone for now.
The majority of the nodejs daemons are related to commercial/closed-source modules. Three that I see on a running PBXact are sangomaconnect, sangomartapi, and qcallback-events. How are we in the community supposed to help validate commercial modules?
For open-source modules: I updated nodejs to v22 on a system and encountered no errors with the ucp or fastagi (core) daemons.
Good question – open source community members can’t do that, but, commercial partner community members can (and do, regularly, through numerous BETA programs.)
Solid, nice work, thank you!
EDIT: to add to your OS list pm2 and api – which also makes it majority OS, per your commercial count – even without stretching to xmpp. Please share your patches in GH!
As I reported in the linked post, I have upgraded those packages at the time of the post and have had no issues since then. I had not posted a list of used modules in our environment as requested, but in general we use sysadmin and endpoint and uninstall all the rest of the commercial modules.
the better!
– even without stretching to