g+
g+ Communities
Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
<== Date ==> <== Thread ==>

Subject: On compatibility
From: Dirk Zimoch <dirk.zimoch@psi.ch>
To: "J. Lewis Muir" <jlmuir@imca-cat.org>
Cc: Eric Norum <wenorum@lbl.gov>, "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Tue, 29 May 2012 09:56:30 +0200
Hi folks,

Meanwhile this thread is totally out of topic. :-)

I like backward compatibility. This allows to take care only of the changes that I really need.

When upgrading to a new version of a certain (3rd party) driver, I usually spend some time on tracking the changes. I do that because of bad experience. Drivers change behavior, change APIs and so on. Recent example: base 3.14.12 broke the ca gateway because of an API change. Other example: the OMS VME58 driver once dropped one (unused) argument from it's configuration function. Everybody had to change their startup scripts. These changes usually induce a lot of work in addition to simply downloading the new code and compiling it.

When there are many cross-dependencies like in areaDetector, things are getting worse. Suddenly I have to track changes in 5 or more other modules (and maybe they require further updates and so on). This costs me a lot of my time. This is why I would appreciate to have more flexibility in mixing versions and to be able to upgrade only that what I really need and want to upgrade.

By the way, I also appreciate binary compatibility. Up to EPICS base 3.14.8 (maybe even up to 3.14.11), large parts of base were binary compatible. I could for example upgrade all extensions just by upgrading base. 3.14.12 broke this mechanism.

Some guidelines would help to to keep binary compatibility:

Do not remove API functions or change their arguments. Do not change the meaning (e.g. units) of an argument. Better write additional API functions if necessary.

Do not remove or reorder fields of interface structures. Do not insert fields in the middle. Add them at the end. Keep supporting old fields.

Do not remove shared libraries.

Also put version macros into your header files if they are used by other code. This allows other code to deal with different interfaces.

It *is* possible to improve software without breaking all existing interfaces.

Or do it like the Linux kernel developers do: Someone who changes an interface is responsible for fixing (and testing ?) all drivers that use that interface. This of course only works when all drivers are in one common repository.

At the moment I am very hesitant when it comes to upgrades of third party drivers because of all the unknown side effects.

Dirk


J. Lewis Muir wrote:
On 5/25/12 1:18 PM, Mark Rivers wrote:
Lewis,

I think your point and Dirk's are rather different.  You are
saying "don't support old releases of modules you are
responsible for".  Fine.  But Dirk is saying "do write your
module X so it supports old versions of module Y that someone
else is responsible for".  In the case of streamDevice that
means old versions of base and asyn.

In the case of more complex modules like areaDetector, it
would potentially mean I should support old versions of base,
asyn, calc, busy, sscan, and autosave.

I just don't think that's realistic or a good use of my
limited time.

Hi, Mark.

OK, maybe I misunderstood what Dirk was saying.  I agree that it
can be very time consuming to do Dirk's approach, and I agree
that, with limited time, it might not be the best choice, but
I'm just saying what Dirk did is nice because StreamDevice is
able to work with older versions of libraries which means I
could potentially upgrade just StreamDevice and nothing else.

What I thought Dirk was talking about was the concept of binary
compatibility and trying not to break that for a reasonable
amount of time.  There's a write-up about that at

http://apr.apache.org/versioning.html

.  I like this and think it would make dealing with all the
EPICS related libraries out there a lot easier because I could
very quickly tell what versions of libraries I could expect to
upgrade and still work correctly with one another.  And it would
require developers to be aware of binary compatibility since
they'd have to increment the right version number part.  Now I
just need to convince everyone to adopt this versioning scheme. :-)

Lewis



Replies:
RE: On compatibility michael.abbott
References:
"@init handler failed" , "Record initialization failed" and "No reply from device within 1000 ms" 洪春霞
Re: "@init handler failed" , "Record initialization failed" and "No reply from device within 1000 ms" Eric Norum
Re: "@init handler failed" , "Record initialization failed" and "No reply from device within 1000 ms" Dirk Zimoch
Re: "@init handler failed" , "Record initialization failed" and "No reply from device within 1000 ms" Andrew Johnson
Re: "@init handler failed" , "Record initialization failed" and "No reply fro device within 1000 ms" J. Lewis Muir
RE: "@init handler failed" , "Record initialization failed" and "No reply fro device within 1000 ms" Mark Rivers
Re: "@init handler failed" , "Record initialization failed" and "No reply fro device within 1000 ms" J. Lewis Muir

Navigate by Date:
Prev: CSS-BOY combo boxes Christian Roehrig
Next: RE: On compatibility michael.abbott
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
Navigate by Thread:
Prev: Re: "@init handler failed" , "Record initialization failed" and "No reply fro device within 1000 ms" J. Lewis Muir
Next: RE: On compatibility michael.abbott
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICSv4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·