Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to deal with no longer supported runtimes (or other components) #594

Open
ManuelFeller opened this issue May 31, 2021 · 3 comments
Open
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@ManuelFeller
Copy link
Member

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.

@ManuelFeller ManuelFeller added enhancement New feature or request help wanted Extra attention is needed labels May 31, 2021
@michaelsauter
Copy link
Member

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.

@clemensutschig
Copy link
Member

@michaelsauter - is there a break in nodejs 10 > 12 .. ? if not, I would dump 10 completely now...

@ManuelFeller
Copy link
Member Author

ManuelFeller commented Jun 1, 2021

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants