You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@plc4x.apache.org by Christofer Dutz <ch...@c-ware.de> on 2020/11/20 11:07:53 UTC
[DISCUSS] How about changing the way we act on "backward
compatability"?
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 really know who is actually using what. And in the past I have seen multiple times that stuff I was thought to be used, actually couldn’t have and I was wasting my energy in keeping things compatible while it would have been better to change them.
So how about we call out loud on all channels that we promise to pay attention to parts we know are being used. And the only way we can know about this, is if the companies actually tell us.
I’d even call it out as “We are working hard on reaching the version 1.0.0 and for this we might want to clean up and change a few things”.
This way we can assure we evolve the different parts as freely as possible. If someone complains that we broke something they were using, we’ve got an excuse and perhaps we’ll get more official statements about usage this way?
What do you think?
Chris
Re: [DISCUSS] How about changing the way we act on "backward
compatability"?
Posted by Christofer Dutz <ch...@c-ware.de>.
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 in parallel I'm playing around on the subscription API (But doing that in PLC4GO as I know I won't be breaking anything there).
The Connection-, Read- and Write-API we have already changed multiple times in the past years, and I'm pretty happy with them the way they are.
I was more referring to the numerous integration modules we are maintaining. Here we sometimes try to keep things compatible without even knowing if there's a need to ... I mean ... no need jumping some extra hoops for keeping something compatible to something no one uses ;.)
I know from other projects, that there are some that keep the API stable at all costs, which usually is not good as it can't evolve.
Others keep on breaking the API which causes developers and maintainers to curse.
I think we need to find a way in-between.
So I would propose to try to keep the most used parts as stable as possible and let the ones that aren't widely used mature as seems needed.
Which - of course - brings up the question: Which are used and which are not? ... So that was why I proposed to announce that we'll concentrate on keeping the ones people claim to be using more stable and let the ones no one talks about mature without any restriction.
Chris
Am 20.11.20, 15:49 schrieb "Stephen Snow" <s4...@gmail.com>:
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 something of the legacy API to progress the project in order
to bring enhancement to the capabilities. Having said this, what about
taking the approach that JDK did when transitioning through Ver 8 to
13, fork the legacy source. Work on the new API with intent to
achieving Ver 1.0.0 while only maintaining the legacy at Ver 0.8.0 and
only minor rev's until your ready to switch. And wherever possible
provide good directions on converting to the new and improved API? Then
when you're confident you have the new approach hammered out
sufficiently to support a change to it, then make the change. Goal
oriented change management is a must I think.
Just my 2c worth.
Best regards,
Stephen
On Fri, Nov 20, 2020 at 06:32, Otto Fowler <ot...@gmail.com>
wrote:
> or, we can follow versioning rules and have the ‘new kafka sink’
> trigger a
> proper release that allows breaking backwards compatibility
>
> From: Christofer Dutz <christofer.dutz@c-ware.de
> <ma...@c-ware.de>>
> <christofer.dutz@c-ware.de <ma...@c-ware.de>>
> Reply: dev@plc4x.apache.org <ma...@plc4x.apache.org>
> <dev@plc4x.apache.org <ma...@plc4x.apache.org>>
> <dev@plc4x.apache.org <ma...@plc4x.apache.org>>
> Date: November 20, 2020 at 06:08:51
> To: dev@plc4x.apache.org <ma...@plc4x.apache.org>
> <dev@plc4x.apache.org <ma...@plc4x.apache.org>>
> <dev@plc4x.apache.org <ma...@plc4x.apache.org>>
> Subject: [DISCUSS] How about changing the way we act on "backward
> compatability"?
>
> 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
> really
> know who is actually using what. And in the past I have seen multiple
> times
> that stuff I was thought to be used, actually couldn’t have and I
> was
> wasting my energy in keeping things compatible while it would have
> been
> better to change them.
>
> So how about we call out loud on all channels that we promise to pay
> attention to parts we know are being used. And the only way we can
> know
> about this, is if the companies actually tell us.
>
> I’d even call it out as “We are working hard on reaching the
> version 1.0.0
> and for this we might want to clean up and change a few things”.
>
> This way we can assure we evolve the different parts as freely as
> possible.
> If someone complains that we broke something they were using, we’ve
> got an
> excuse and perhaps we’ll get more official statements about usage
> this way?
>
> What do you think?
>
> Chris
Re: [DISCUSS] How about changing the way we act on"backward
compatability"?
Posted by Stephen Snow <s4...@gmail.com>.
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 something of the legacy API to progress the project in order
to bring enhancement to the capabilities. Having said this, what about
taking the approach that JDK did when transitioning through Ver 8 to
13, fork the legacy source. Work on the new API with intent to
achieving Ver 1.0.0 while only maintaining the legacy at Ver 0.8.0 and
only minor rev's until your ready to switch. And wherever possible
provide good directions on converting to the new and improved API? Then
when you're confident you have the new approach hammered out
sufficiently to support a change to it, then make the change. Goal
oriented change management is a must I think.
Just my 2c worth.
Best regards,
Stephen
On Fri, Nov 20, 2020 at 06:32, Otto Fowler <ot...@gmail.com>
wrote:
> or, we can follow versioning rules and have the ‘new kafka sink’
> trigger a
> proper release that allows breaking backwards compatibility
>
> From: Christofer Dutz <christofer.dutz@c-ware.de
> <ma...@c-ware.de>>
> <christofer.dutz@c-ware.de <ma...@c-ware.de>>
> Reply: dev@plc4x.apache.org <ma...@plc4x.apache.org>
> <dev@plc4x.apache.org <ma...@plc4x.apache.org>>
> <dev@plc4x.apache.org <ma...@plc4x.apache.org>>
> Date: November 20, 2020 at 06:08:51
> To: dev@plc4x.apache.org <ma...@plc4x.apache.org>
> <dev@plc4x.apache.org <ma...@plc4x.apache.org>>
> <dev@plc4x.apache.org <ma...@plc4x.apache.org>>
> Subject: [DISCUSS] How about changing the way we act on "backward
> compatability"?
>
> 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
> really
> know who is actually using what. And in the past I have seen multiple
> times
> that stuff I was thought to be used, actually couldn’t have and I
> was
> wasting my energy in keeping things compatible while it would have
> been
> better to change them.
>
> So how about we call out loud on all channels that we promise to pay
> attention to parts we know are being used. And the only way we can
> know
> about this, is if the companies actually tell us.
>
> I’d even call it out as “We are working hard on reaching the
> version 1.0.0
> and for this we might want to clean up and change a few things”.
>
> This way we can assure we evolve the different parts as freely as
> possible.
> If someone complains that we broke something they were using, we’ve
> got an
> excuse and perhaps we’ll get more official statements about usage
> this way?
>
> What do you think?
>
> Chris
Re: [DISCUSS] How about changing the way we act on "backward compatability"?
Posted by Niclas Hedhman <ni...@hedhman.org>.
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 areas where incompatibility can improve the overall codebase.
Postponing it only hurts more later.
Niclas
On Fri, Nov 20, 2020 at 3:47 PM Christofer Dutz <ch...@c-ware.de>
wrote:
> 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 cared about the incompatibility. And if we bump the major
> version all the time people could be annoyed of us breaking things all the
> time ;-)
>
> Chris
>
>
>
>
>
> Am 20.11.20, 15:32 schrieb "Otto Fowler" <ot...@gmail.com>:
>
> or, we can follow versioning rules and have the ‘new kafka sink’
> trigger a
> proper release that allows breaking backwards compatibility
>
> From: Christofer Dutz <ch...@c-ware.de>
> <ch...@c-ware.de>
> Reply: dev@plc4x.apache.org <de...@plc4x.apache.org> <
> dev@plc4x.apache.org>
> Date: November 20, 2020 at 06:08:51
> To: dev@plc4x.apache.org <de...@plc4x.apache.org> <de...@plc4x.apache.org>
> Subject: [DISCUSS] How about changing the way we act on "backward
> compatability"?
>
> 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 really
> know who is actually using what. And in the past I have seen multiple
> times
> that stuff I was thought to be used, actually couldn’t have and I was
> wasting my energy in keeping things compatible while it would have been
> better to change them.
>
> So how about we call out loud on all channels that we promise to pay
> attention to parts we know are being used. And the only way we can know
> about this, is if the companies actually tell us.
>
> I’d even call it out as “We are working hard on reaching the version
> 1.0.0
> and for this we might want to clean up and change a few things”.
>
> This way we can assure we evolve the different parts as freely as
> possible.
> If someone complains that we broke something they were using, we’ve
> got an
> excuse and perhaps we’ll get more official statements about usage this
> way?
>
> What do you think?
>
> Chris
>
>
Re: [DISCUSS] How about changing the way we act on "backward
compatability"?
Posted by Christofer Dutz <ch...@c-ware.de>.
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 cared about the incompatibility. And if we bump the major version all the time people could be annoyed of us breaking things all the time ;-)
Chris
Am 20.11.20, 15:32 schrieb "Otto Fowler" <ot...@gmail.com>:
or, we can follow versioning rules and have the ‘new kafka sink’ trigger a
proper release that allows breaking backwards compatibility
From: Christofer Dutz <ch...@c-ware.de>
<ch...@c-ware.de>
Reply: dev@plc4x.apache.org <de...@plc4x.apache.org> <de...@plc4x.apache.org>
Date: November 20, 2020 at 06:08:51
To: dev@plc4x.apache.org <de...@plc4x.apache.org> <de...@plc4x.apache.org>
Subject: [DISCUSS] How about changing the way we act on "backward
compatability"?
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 really
know who is actually using what. And in the past I have seen multiple times
that stuff I was thought to be used, actually couldn’t have and I was
wasting my energy in keeping things compatible while it would have been
better to change them.
So how about we call out loud on all channels that we promise to pay
attention to parts we know are being used. And the only way we can know
about this, is if the companies actually tell us.
I’d even call it out as “We are working hard on reaching the version 1.0.0
and for this we might want to clean up and change a few things”.
This way we can assure we evolve the different parts as freely as possible.
If someone complains that we broke something they were using, we’ve got an
excuse and perhaps we’ll get more official statements about usage this way?
What do you think?
Chris
Re: [DISCUSS] How about changing the way we act on "backward compatability"?
Posted by Otto Fowler <ot...@gmail.com>.
or, we can follow versioning rules and have the ‘new kafka sink’ trigger a
proper release that allows breaking backwards compatibility
From: Christofer Dutz <ch...@c-ware.de>
<ch...@c-ware.de>
Reply: dev@plc4x.apache.org <de...@plc4x.apache.org> <de...@plc4x.apache.org>
Date: November 20, 2020 at 06:08:51
To: dev@plc4x.apache.org <de...@plc4x.apache.org> <de...@plc4x.apache.org>
Subject: [DISCUSS] How about changing the way we act on "backward
compatability"?
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 really
know who is actually using what. And in the past I have seen multiple times
that stuff I was thought to be used, actually couldn’t have and I was
wasting my energy in keeping things compatible while it would have been
better to change them.
So how about we call out loud on all channels that we promise to pay
attention to parts we know are being used. And the only way we can know
about this, is if the companies actually tell us.
I’d even call it out as “We are working hard on reaching the version 1.0.0
and for this we might want to clean up and change a few things”.
This way we can assure we evolve the different parts as freely as possible.
If someone complains that we broke something they were using, we’ve got an
excuse and perhaps we’ll get more official statements about usage this way?
What do you think?
Chris
Re: [DISCUSS] How about changing the way we act on "backward compatability"?
Posted by Lukas Ott <ot...@gmail.com>.
+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
someone is using PLC4X then they can tell us here on the mailing list so we
can pay attention and consider that.
Am Fr., 20. Nov. 2020 um 12:08 Uhr schrieb Christofer Dutz <
christofer.dutz@c-ware.de>:
> 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 really
> know who is actually using what. And in the past I have seen multiple times
> that stuff I was thought to be used, actually couldn’t have and I was
> wasting my energy in keeping things compatible while it would have been
> better to change them.
>
> So how about we call out loud on all channels that we promise to pay
> attention to parts we know are being used. And the only way we can know
> about this, is if the companies actually tell us.
>
> I’d even call it out as “We are working hard on reaching the version 1.0.0
> and for this we might want to clean up and change a few things”.
>
> This way we can assure we evolve the different parts as freely as
> possible. If someone complains that we broke something they were using,
> we’ve got an excuse and perhaps we’ll get more official statements about
> usage this way?
>
> What do you think?
>
> Chris
>