Hi Stephen,
thanks for your opinion on this ... it's highly appreciated.
Well I think the we're currently not planning on changing the existing API too
much.
Right now I'm working on making some meta-data for a connection available. But
this is more an extension and not a breaking change.
And
Everyone knows that 0.x == "unstable interfaces" and those willing to use
0.x (like me) do expect "hassle" when moving on to 1.0 and beyond. The 0.x
to 1.x transition is extra unique as there are typically a lot less users
than a 1.x to 2.x incompatibility jump. So, my recommendation is; Tackle
all
Hello,
My name is Stephen Snow, and I am a Solution Provider of Industrial
Automation for some customers I have. I am curently starting a project
that I am hoping to sell to my customers in various forms, that will
likely use the PLC4X API. I am comfortable, FWIW, with new major rev's
breaking
Hi Otto,
I would not like to start Semver exactly now ... and it doesn't help if we
start bumping major versions with every release.
In the end this wouldn't really change anything. If we bump the major version
number it's still incompatible with the old one and we don't know if anyone
even ca
or, we can follow versioning rules and have the ‘new kafka sink’ trigger a
proper release that allows breaking backwards compatibility
From: Christofer Dutz
Reply: dev@plc4x.apache.org
Date: November 20, 2020 at 06:08:51
To: dev@plc4x.apache.org
Subject: [DISCUSS] How about changing the wa
+1 , especially your progress and changes you did via Go and porting that
back to Java helped the Python attempt potentially a lot to get started. So
I think we should break things for the mentioned reasons as we have so many
new features and improvements that will be available in 0.8 ! And yes if
chrisdutz commented on pull request #202:
URL: https://github.com/apache/plc4x/pull/202#issuecomment-731116108
This is definitely a valid scenario, so I would suggest to change it.
This is an automated message from the Apache
hutcheb commented on pull request #202:
URL: https://github.com/apache/plc4x/pull/202#issuecomment-731115622
I've been going back and froth between changing the schema for the source
connector and the initial reason for it was so that we don't change the schema.
Avro and the schema registr
Hi all,
in a discussion with Ben on the Kafka Connect adapter. He was trying to stay
compatible with the past in order to not break anything with existing
installations. As of know I don’t know of a single usage of it anywhere.
The thing is: we developed a lot of stuff and as of now we don’t re
chrisdutz edited a comment on pull request #202:
URL: https://github.com/apache/plc4x/pull/202#issuecomment-731099735
As far as I know nobody is publicly using it ... :-/
So I would say: If it would be better to change things ... do it now before
we're actually listed in the Confluen
chrisdutz commented on pull request #202:
URL: https://github.com/apache/plc4x/pull/202#issuecomment-731099735
As far as I know nobody is publicly using it ... :-/
This is an automated message from the Apache Git Service.
To
hutcheb commented on pull request #202:
URL: https://github.com/apache/plc4x/pull/202#issuecomment-731090926
Worked through the Confluent checklist as well as added tests and
documentation.
- The schema for the source has remained unchanged, I have brought the sink
connector schema
12 matches
Mail list logo
