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

Reply via email to