| 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 | 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 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | On compatibility |
| From: | Dirk Zimoch <[email protected]> |
| To: | "J. Lewis Muir" <[email protected]> |
| Cc: | Eric Norum <[email protected]>, "[email protected]" <[email protected]> |
| 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