Re: [DISCUSS] How about changing the way we act on "backward compatability"?

[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