Well .. sticking all API versions together I don’t really see the benefit.
Right now, our API versions are also not fully aligned with each other.
It’s less important that PLC4J-API matches PLC4J-Driver than that PLC4J-API
matches PLC4Go-API.
And the problems I see that can evolve … immagine we release a new driver and
that uses a new version of the API and we don’t release the other drivers as we
didn’t change things.
Now in a JVM application running multiple drivers and not using OSGI or alike,
which version would be used? The newer one and the new driver works and breaks
the old ones or you use the old API and will have trouble running the new
driver.
Right now, people are used to using a „PLC4J-version“ and that ensures
everything fits together.
Chris
Von: Sebastian Rühl <[email protected]>
Datum: Donnerstag, 20. November 2025 um 17:37
An: [email protected] <[email protected]>
Betreff: Re: AW: Suggestion to introduce dedicated repos for API, SPI and
languages
Answers inline:
On 2025/11/20 16:11:22 Christofer Dutz wrote:
Hi Sebastian,
Well SPI would more be part of the language, right?
And API would not be a „plc4x-api“ but a „plc4j-api“, „plc4go-api“,
„plc4py-api“ right?
I would aggregate api/spi in the first step. No urgent need to have the
seperated besides the inability to use go tags (could be solved by a
manipulated tag).
Dammit … you already mentioned most of my objections 😉 Yes we would be adding
10 repos … and even if we would not release the API modules if nothing has
changed, still would we need to release all language modules. Or we only
release language modules, if we worked on them (However then I think we’ll
simply stop releasing some of them and effectively move them to some sort of
project attic). We also need to keep in mind, that our code-generation is Java
based, so you’ll not really make things 100% native by splitting up. Also
should we not forget, that we have quite some interdependencies … like we use
the PLC4J part to generate part of the documentation for the website.
The reasoning I do understand and I have seen this type of discussion before.
In Apache Cocoon the project switched to releasing only modules that had
changes. This was a very clean approach, but from a user-perspective it was a
nightmare. If you wanted to use module X you had to search for which API
version that works with. Many issues here also only popped up at runtime, which
made things even worse.
Not sure if that would be a problem as when you pull in a driver version that
would include a API version transitive. Don't see the issue yet we could have.
I do like your idea of a sub-module … so far we only have GO as one of these
source-based repos, right? Couldn’t we simply create a new repo and mount part
of the PLC4X repo there? Or we simply fork out the PLC4Go module and link it
back in via git-submodules?
I think python is source based too? If at some point we add typescript support
that would be a source one to I think, but not 100% sure.
In general I would be in favor of one repo per language. Especially as it seems
I might really get funding and then I would start working on the SPI 3.0 for
PLC4J … if we didn’t move PLC4J in this new repo, but I would start building a
completely new one there, this would simplify things.
sure that would be a benefit of having a split API/SPI. We could do that also
on demand as breakout and then re-aggregate with submodule/subtree..
- Sebastian
