Hi all, The one thing I’m worried about, when splitting the repo, is the amount of work added for releasing all parts. If we support N languages it’s N-times the work for creating the release and N-times the work for reviewing them (If you actually review and don’t just wave them through - which nobody should do).
I am not entirely sure if anyone else here has formally done a release other than myself (I thought I remembered one occasion, but can’t remember who it was). The other alternative would be to release the languages independently. So if all energy goes into Java and Go, we’d only release them. Admittedly I wouldn’t like that. So I’m more leaning towards keeping things together and possibly creating a separate repo for PLC4go and using Git Submodules to link it back in. This way we wouldn’t need to change anything in the build and the release process (I would need to check however, if really nothing is needed to be changed to push all the tags etc, but I’d be happy to do the research) Chris Von: Łukasz Dywicki <[email protected]> Datum: Montag, 24. November 2025 um 19:13 An: [email protected] <[email protected]> Betreff: Re: AW: AW: AW: Suggestion to introduce dedicated repos for API, SPI and languages Hello, I think we should make releases more often, and only then think of fine grained releases. Having an API release makes a ton of sense for specification based project, where API serves closely some well defined purpose and have clear use. I don't think we are there yet. While separating API/SPI/driver/language releases is great from technical perspective, it is quite difficult to orchestrate and provide patch releases on top of these. It simply multiplies amount of things to push over. Having a release per language is fair choice, but given dominance of Go/Java over others I think we can still synchronize these two. I recall that Apache Aries did per-module releases (using single SVN/git root!) and it caused a lot of struggle for end users which had to spend more time to find working set of modules. Even if our language related modules (api, spi, drivers) are streamlined, they may still have dependency paths among each other or conflicting dependencies over time. For now I'd abstain from making more work on releases, but if you are willing to commit effort into it to make it work, feel free to go. Maybe ASF Trusted Releases could offload some of the work from you, so it will become click & release? :) Best, Łukasz On 11/20/25 21:13, Christofer Dutz wrote: > 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 >>
