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
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- 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
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|