You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #593 we came across that we now have a node 10 build agent while node 10 itself it goes out of LTS just today.
This means if anything breaks inside of node 10 and we still need to keep the agent buildable we will need to fix node on our own to solve the problem. This may lead to a huge issue regarding maintenance effort, so we should come up with a way how we will handle this in the future - to communicate it and to also be able to act accordingly.
And I assume that this would not just affect node, but potentially also other runtimes.
We could e.g. try to align our releases with the LTS timelines, but I guess due to the ammount of different runtimes this may be a bit tricky.
Or we could always try to have two current LTS ones and state that we only support X's agent as long as X also has LTS. Or even say we may add a new agent with X's newest LTS within a ODS version.
The text was updated successfully, but these errors were encountered:
I believe the root issue here is that we released ODS 3.0.0 with node 10, when we should have picked a more recent version as node 10 was already ancient back then. ODS releases should have a certain lifetime for which we envision support (e.g. 1 or 2 years), and at least major tech like node should be at a version which should allow for this goal to be feasible.
For the specific problem we face now, we could release ODS 3.2.0 with node 12, potentially breaking users if admins just override the 3.x tag in their ODS installation. Or we somehow get node 10 to work and don't dig deeper. I think I would prefer this in this case ... if it is not a lot of effort to fix the issue.
There may be, depending what you do: https://nodejs.org/tr/blog/uncategorized/10-lts-to-12-lts/#notable-changes
And that is a quite long list of mostly small but sometimes behavioural changing or removing differences - not sure if each potential user would still have completely running builds, even if we did not have any known issues so far...
Especially some fs changes (.read requiring callbacks, removed .syncWriteStream, ...) may break custom build time logic.
As said this should not "just" the node 10 is out of LTS topic (especially as it solved itself and showed up another issue in a quick starter), but a general strategy for the future how to deal with those things (as other runtimes or included tools may also run out of support some time)
I will drive this a bit more from next week onwards with suggestions, this week is a bit tight for me...
In #593 we came across that we now have a node 10 build agent while node 10 itself it goes out of LTS just today.
This means if anything breaks inside of node 10 and we still need to keep the agent buildable we will need to fix node on our own to solve the problem. This may lead to a huge issue regarding maintenance effort, so we should come up with a way how we will handle this in the future - to communicate it and to also be able to act accordingly.
And I assume that this would not just affect node, but potentially also other runtimes.
We could e.g. try to align our releases with the LTS timelines, but I guess due to the ammount of different runtimes this may be a bit tricky.
Or we could always try to have two current LTS ones and state that we only support X's agent as long as X also has LTS. Or even say we may add a new agent with X's newest LTS within a ODS version.
The text was updated successfully, but these errors were encountered: