A Sincere Note About Version Updates – With a Specific Warning on “Column Combiner” ** Ubuntu

umutcankurt · July 5, 2025, 7:08pm

Dear KNIME Development Team,

I have been using KNIME since 2018. Watching a platform grow, improve, and gain new features is a wonderful thing — and I truly appreciate your continued efforts.

BUT…!

There’s a critical problem I feel must be voiced — especially on behalf of users like myself who manage hundreds or even thousands of workflows.

If each new update causes previously working nodes to break or behave inconsistently, this is not just a minor bug — it’s a serious issue.

Every time you change the interface or underlying mechanics of a node, there is a high risk of introducing subtle bugs or unexpected behavior. I’ve noticed this in the past with specific nodes and raised similar concerns during previous updates.

When I build a workflow today, I do so with the latest and best available tools — but an update tomorrow might break that very same workflow. Detecting such issues across thousands of workflows is like finding a needle in a haystack — or playing bingo with broken nodes.

As I close, I want the QA and development teams to please remember:
Even a small UI tweak or functional change — if not thoroughly tested for backward compatibility — can lead to massive time loss, wasted effort, and user frustration. Fixing these problems takes hours or even days for users. Please don’t underestimate this impact.

Current problematic node: Column Combiner
Try combining two columns without any separator using the previous version of this node, and then try the same with the latest version. Do you get the same result? Probably not. That’s exactly the problem.

Additionally, the interface in the updated nodes loads slowly. The tested device’s details are shown in the image. The system is Ubuntu.

With all due respect and appreciation for your work,
Sincerely,

hmfa · July 5, 2025, 9:48pm

Hi.
I leave you a set of general tasks, based on good practice, that ensure a smoother, safer, and more predictable software update process, minimizing risks and maximizing system reliability:

-Make an Inventory of current software, hardware, and configurations.
-Check compatibility and document system requirements.
-Identify potential risks of upgrading and problem areas.
-Define upgrade phases and milestones.
-Assign roles and responsibilities.
-Document risks, backup plans, and communication strategies.
-Perform complete backups of all critical data and custom code.
-Verify backup integrity in advance.
-Set up redundancy (e.g., secondary emvironment ) to minimize downtime.
-Schedule updates during off-peak hours to reduce user impact.
-Notify all stakeholders and users in advance.
-Provide clear information on expected downtime and changes.
-Test the updates in a non-production (staging) environment, never in production.
-Use a test audience for regression testing.
-Roll out updates in phases (pilot group, then wider deployment) to catch issues early.
-Automate repetitive upgrade tasks where possible.
-Monitor system performance, resource usage, and logs during and after deployment.
-Use real-time monitoring tools to detect and address issues quickly.
-Prepare a rollback plan in case the update fails.
-Ensure procedures are in place to quickly restore previous versions.
-Monitor performance metrics post-upgrade.
-Gather feedback from users and stakeholders.
-Train staff on new features and changes to reduce support requests.
-Keep software and dependencies up to date.
-Document all changes, configurations, and lessons learned for future upgrades.

The must:
-Perform complete backups of all critical data and custom code.
-Verify backup integrity in advance.
-Prepare a rollback plan in case the update fails.
-Ensure procedures are in place to quickly restore previous versions.
-Set up redundancy (e.g., secondary emvironment ) to minimize downtime.
-Test the updates in a non-production (staging) environment, never in production.

Best regards

hotzm · July 7, 2025, 9:44am

Hi @umutcankurt,

we take regressions of node behavior quite seriously, especially if they are in “execution” and produce wrong data (and I really mean that “especially” part).

To avoid regressions, we have many thousands of test workflows that are executed whenever we want to make a change (often these workflows are really old!). However, as with all unit/integration testing, there might be subtle combinations of input values or system state that make it practically impossible to test all combinations: OS x AP version workflow was saved in x AP installation state (extensions, upgrade path over many years, configuration, creative “workarounds”) produces a lot of testing surface alone.

As the platform grows, there must be changes to code. We cannot keep old code around as-is forever when previously true assumptions change. To make regressions less likely we have the above mentioned regression test workflows, for new functionality we have verification steps and a substantial testing protocol before the release. Whenever something slips, we fix the problem and also find improvements to the process that it should not happen again.

Backwards-compatibility is high on our priorities next to correctness. As with all bugs, backwards-compatibility breaks cannot be made impossible, but the test workflows make it much less likely.

As for your specific problem, I cannot see a difference:

I used the attached workflow that I created in 5.2 with the old version of the Column Combiner, using no delimiter. When I open it in 5.5 and execute it, the “Table Difference Checker” says the reference data in the data area is the same as the output table from the Column Combiner. What problem do you encounter?

Column Combiner.knwf (125.6 KB)

umutcankurt · July 7, 2025, 10:17pm

@hotzm Hi,

First of all, thank you for your explanation. The fact that you have many workflows and test cases is not a luxury but rather a serious responsibility. After all, this software is used by thousands of people and runs in production environments, so rigorous testing processes are essential — and we know you’re already doing that.

However, there seems to be one missing detail. While you mentioned differences between versions in your workflow tests, you didn’t specify on which operating systems those tests were performed.

Please try the following test scenario:
On Windows 11 with KNIME version 5.5.0, use the Column Combiner node to combine the following two strings, without adding any spaces or special characters:
https://www.eperolehan.gov.my and /quotation-tender-notice/
Result: https://www.eperolehan.gov.my/quotation-tender-notice/

Then, copy the exact same workflow and run it on Ubuntu with KNIME version 5.4.3.
Let’s see what result you get.

I already know the outcome on my side — I’m curious to see what you’ll observe on your end.

Lastly, since I have a very large number of workflows, I always test thoroughly before transitioning to a new version. That’s why I’m still working with the older version for now.

It behaves as if no settings have been applied — as if everything has been reset. It’s like you just added the Column Combiner node for the first time without configuring any of its settings.

Looking forward to hearing your results.
Thank you again.

Best regards,

ActionAndi · July 8, 2025, 6:34am

Edited 2025-07-08 → it’s a matter of setting in my case → see my comment below
When using 5.5 I do not get the desired result as well. If the “delimiter” is empty the behavior is totally different.

My System is Win10

hotzm · July 8, 2025, 7:26am

@umutcankurt If you’re saving the Column Combiner in 5.5 and opening it in 5.4 it is no wonder it is reset when loaded. When the node settings are not valid (e.g. missing required settings keys), the node is loaded with its default settings. This is why you see

It’s like you just added the Column Combiner node for the first time without configuring any of its settings.

There were changes to the list element for the columns between 5.4 and 5.5, so 5.4 does not understand the settings structure from 5.5 the version of the node.

We guarantee backwards-compatibility, meaning that old workflows can be opened and executed in new versions of KNIME, but not the other way around; that would be forwards-compatibility. Opening a 5.5 workflow in 5.4 does not work with guarantee – that’s why we show a warning when opening such a workflow. How should the 5.4 version understand the changed settings of the 5.5 version “from the future”?

then in the case of the Column Combiner:

@ActionAndi Just to confirm, are you opening a “5.4 workflow” in 5.5 and are seeing different results? Then that would not be backwards-compatible and we have to investigate.

ActionAndi · July 8, 2025, 8:07am

@hotzm:
I just tested 5.4.4: the behaviour is exactly the same like in 5.5.0

In this case I think the settings are a bit tricky:
If you combine two columns with string entries like
Col1 Col2
a b
and select a delimiter like “+”
the result is
a+b

If you remove the delimiter, the result is “a”“b”. One would expect “ab”.

This is a result of the advanced setting “Quote inputs → Only necessary”

hotzm · July 8, 2025, 8:20am

This is what I would expect from the node description as well. But I tested it in 5.2 and 4.7 with the old version of the node, and the behavior is the same (one can see the double quotation marks at the boundary):

So it seems with no delimiter, the behavior has always been unexpected. I’ll forward this to the team to see how we can best improve this (without breaking existing workflows that might rely on that behavior).

If you choose “replace delimiter” by empty string, it works as expected and just concatenates both strings.

(I added it as internal ticket UIEXT-2843)

umutcankurt · July 8, 2025, 2:49pm

Hi,
Thank you to everyone for all the responses and reviews.
It was important to have the issue identified more clearly and transparently.
I hope it will be resolved in the next update.