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
