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
