hmm I would have left the API and SPI aggregated as those are meant to stick
close, but this comes at the cost of a mini mono repo again. So in the first
step I would just have plc4x-api, plc4x-spi.
- Sebastian
On 2025/11/20 16:17:51 Christofer Dutz wrote:
> Oh …
> and mabe adding to this … a new release would then be:
>
>
> *
> Release build-tools (If something changed)
> *
> Release protocols (If something changed)
> *
> Release API4{X} (if something changed)
> *
> Release PLC4{X) (If something changed)
> *
> Release / Update Website (Obviously something must have changed)
>
> Working with half released stuff and releasing all in one go will be very
> difficult for non-maven-professionals.
>
>
> Chris
>
> Von: Christofer Dutz <[email protected]>
> Datum: Donnerstag, 20. November 2025 um 17:13
> An: [email protected] <[email protected]>
> Betreff: AW: Suggestion to introduce dedicated repos for API, SPI and
> languages
>
> 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?
>
> 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.
>
> 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?
>
> 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.
>
> Chris
>
>
>
> Von: Sebastian Rühl <[email protected]>
> Datum: Donnerstag, 20. November 2025 um 16:58
> An: [email protected] <[email protected]>
> Betreff: Suggestion to introduce dedicated repos for API, SPI and languages
>
> Hi together,
>
> after some thoughts and discussions it came clear that it would be a good
> move to introduce dedicated repos for:
> - API (plc4x-api)
> - SPI (plc4x-spi)
> - Lanugages (plc4j, plc4go, plc4py)
>
> The idea is to have it like in slf4j. They have their slf4j-api package and
> then different implementations that you can throw in. For plc4x we could have
> the same where the version of the API then really reflects changes on the API
> itself, the SPI would be the driver-devel-kit and the languages could have
> their own repo without all other languages interfering (The current approach
> for example is a nightmare for source based languages like Go where you
> always pull in this huge behemoth of our mono-repo plc4x). We can still keep
> plc4x as monorepo and then pull in the parts as subtree/git-submodules so we
> can keep that as compability/convenience.
> One could say: oh but now I need to release 10 repos. But I would counter to
> that: why would you need to release, lets say the API, if nothing didn't
> change there.
> Also what I quite like on this approach that it could allow for drop in
> replacements for other OpenSource solutions or even commercial offerings.
> Also that would put PLC4X in a spot where it belongs to: A API for PLCs. :)
>
> So my vote would be with a big +1 to introduce new repos and have that all a
> bit more manageable.
>
> - Sebastian
>
