Apply SemVer … bloody auto-correct. Von: Christofer Dutz <[email protected]> Datum: Donnerstag, 20. November 2025 um 18:08 An: [email protected] <[email protected]> Betreff: AW: AW: AW: Suggestion to introduce dedicated repos for API, SPI and languages
Ok … If we started with a 1.0.0 for the API and if we change the API and apply server, then this module should probably never get a bugfix-release. Then I agree that this would be less of an issue. But everyone working on drivers would be required to 100% pay attention to this. Chris Von: Sebastian Rühl <[email protected]> Datum: Donnerstag, 20. November 2025 um 18:03 An: [email protected] <[email protected]> Betreff: Re: AW: AW: Suggestion to introduce dedicated repos for API, SPI and languages but the alignment of the API cross languages is the X in plc4x. Or at least the should be similar. But I'm completely fine with splitting that up. On your second argument: The leading version is the driver which then has the dependency on the API. So that should give a clue to what API this driver is compatible. I don't see a huge deal with that. But maybe I miss something - Sebastian On 2025/11/20 16:49:53 Christofer Dutz wrote: > 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 >
