Thank you for further clarifying the new release cycle — it helped me rethink my setup.
To streamline things, I’m consolidating down to just two update sites instead of one per version:
Standard releases: I’ll build against the current version whenever I publish a new extension release. Because KNIME maintains backward compatibility, there’s no need to rebuild with every KNIME release.
LTS releases: I’ll build against the oldest supported LTS, which automatically covers all newer LTS versions. Not being able to use the very latest features is fine for my purposes.
This setup maintains compatibility while significantly reducing overhead. From what I can tell, it aligns perfectly with KNIME’s release model, so I don’t expect any issues. However, if there’s a corner case I haven’t considered, I’d love to hear about it.
Best
Lorenz
P.S. Quick side question: where can I find the “Latest” build job in Jenkins mentioned in the FAQ?
some pieces for Community and Partner Extensions are not yet there.
There will be a Latest build job soon, which we will then use for the standard releases. Only one. We will trigger that again every six weeks.
Apart from that, everything else will just stay the same for Community and Partner developers. Meaning: for every LTS release there will be a new build job just as in the previous years.
I did not understand what you meant with “custom update site”, what is that?
I admit, I also don’t really understood what you meant with " consolidating down to just two update sites instead of one per version". But I hope my previous explanations resolved the confusion.
Thanks for clarifying the details about the Hub builds.
About the “custom update site”, I should have been clearer earlier. What I meant was a self-hosted update site I’m running in parallel to the Hub. I don’t want to dive into the reasons behind this setup; it’s simply the approach I’d like to keep for now.
I’d love to hear your thoughts on whether maintaining a self-hosted update site, as described above, makes sense for KNIME’s future release cycle.
Hi Lorenz, I don’t have details on why and how you set up your self-hosted update site, so I can only refer to my points above.
However, regarding your points further above:
Standard releases: KNIME maintains backwards compatibility for workflows. This cannot hold for extensions, as they need to evolve with KNIME Analytics Platform to guarantee the backwards compatibility. At the same time, for Python extensions there are very few changes necessary regarding the extension maintenance.
LTS releases: No. No. No. See 1.: There can be breaking changes - the one (and only) example so far for Python extensions is the change to pixi, which we are currently pursuing. Thus, please don’t rely that what you built for one LTS works for another LTS. Always verify and test.
In addition to latest will there still be nightly (or is it trunk - I can never remember!) - and if so, will that build against the latest LTS or the latest… latest? (I hope the meaning of that is clear?!)
Very valid points, we’re discussing that and will update.
(it is trunk, but I am unsure whether that really was ever used as a nightly or whether it was used as a pure playground - I think playground, but veeery unsure)
I think trunk was the community nightly - (I assume the KNIME core AP ‘nightly’ download also uses a trunk build?). I think the naming comes from back when the source code was hosted on a private KNIME SVN where the SVN-speak equivalent of git’s master or main was trunk, and the nightly build was scheduled to run every night at about 4 or 5 am as opposed to on commit.
We are planning to have a nightly for community that builds against KNIME’s nightly → so using the latest sources available for everything, KNIME and extensions. This allows extension developers to adapt to the next KNIME version before it is released.
As @steffen_KNIME said, there are still some pieces in motion. We’ll update you here as soon as we have the build jobs ready.
1. I’m trying to install KNIME Analytics Platform 5.6, but the following URL returns a “not found” error:
org.knime.update.analytics-platform_5.6.0.zip
I’d like to download the file directly. Could you provide the correct link?
2. Regarding Interactive View nodes, I heard that KNIME is switching from a JSFree-based implementation to an ECharts-based one. Has this change already been applied in the released 5.6 version?
I’m working with large datasets (~500,000 rows), but rendering them in the Interactive View is extremely slow.
If the improvements are not yet included in version 5.6, could you let me know when they are planned to be released?
Hi Carsten, Just for clarity having gone through the thread above, we will have 3 options for Knime downloads.
Twice Yearly LTS versions
6 week rolling Versions
Nightlies.
For those of us that are behind network blockers, How will the Download Page options be structured to allow us to Identify the LTS versions ? Knowing this will be important so we can go through the process of updating our software repositories.
Also, might I suggest a better link to the Extensions repository perhaps somewhere on the Downloads page ? With so many Core releases it might be important to have the extensions more closely linked and viewable.
This is likely the correct link .
The echarts charts should be around since a while already. You find them by looking for the KNIME Views nodes for example on the linked hub. They should perform much better with large data. Let me know once you tried it out.
)