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: | Re: AreaDetector repository inconsistent |
From: | "Mooney, Tim M." <[email protected]> |
To: | "Rivers, Mark L." <[email protected]>, "'J. Lewis Muir'" <[email protected]> |
Cc: | "[email protected]" <[email protected]> |
Date: | Fri, 9 Feb 2018 18:34:38 +0000 |
Hi Mark,
I didn't even notice that what I wrote about module upgrades was deeply misleading.
I should clarify that the impracticality of upgrading a module on which many other modules depend has nothing to do with module incompatibilities. It is purely about deployed - compiled and linked - code. If we have a built synApps support directory, and want to add a new version of, say, the motor module, we just add it, and users can choose which version they want to build with. But if we add a new version of asyn, users can't simply choose the new module, because they are building with many other modules that were built against the original version of asyn, and you can't use two versions of asyn at the same time. So we would need to build a second copy of each of the modules that link against asyn, and make sure people know which goes with which. At that point, it's much cleaner and safer to have a new version of synApps.
Tim Mooney ([email protected]) (630)252-5417
Beamline Controls Group (www.aps.anl.gov) Advanced Photon Source, Argonne National Lab From: Mark Rivers <[email protected]>
Sent: Thursday, February 8, 2018 1:24:59 PM To: 'J. Lewis Muir'; Mooney, Tim M. Cc: Jemian, Pete R.; [email protected] Subject: RE: AreaDetector repository inconsistent Tim said:
>> This works until someone needs a new version of asyn, or seq, or some other > > module that many other modules use. In that case, it's impractical to > > upgrade single modules, and a new version of synApps is needed. I would argue that in most cases upgrading even asyn and seq should not require a new version of any other module. Both packages strive for backwards compatibility. If you upgrade a package that depends on asyn then you may need to update asyn. That is expected, the dependent module may be using a new feature of asyn. This should be documented in the dependent module release notes. But the opposite should not be true, updating asyn should not require updating the module that depends on it. There are sometimes minor changes that require changes in startup scripts, display screens, etc. But I believe that unexpected inter-module dependency problems are rare. Mark > -----Original Message----- > From: J. Lewis Muir [mailto:[email protected]] > Sent: Thursday, February 08, 2018 12:43 PM > To: Mooney, Tim M. <[email protected]> > Cc: Mark Rivers <[email protected]>; Jemian, Pete R. <[email protected]>; tech- > [email protected] > Subject: Re: AreaDetector repository inconsistent > > On 02/07, Mooney, Tim M. wrote: > > I think synApps_x_y.sh is a good idea. By the way, the reason that > > full synApps releases are not more frequent is not mostly about > > module incompatibilities, but more about our inability to test. To > > thoroughly test synApps, you have to get it deployed on a beamline. > > We don't have a test beamline, and beamline staff don't want to expose > > their users to questionable software. They are willing to accept a > > new module version that hasn't been thoroughly tested if there is a > > bug fix or other improvement they need. But they are not willing to > > risk problems from a module whose new features they don't care about. > > So, as long as we can do single module upgrades, we do them. This > > works until someone needs a new version of asyn, or seq, or some other > > module that many other modules use. In that case, it's impractical to > > upgrade single modules, and a new version of synApps is needed. > > Hi, Tim! > > Thanks for the explanation! One thing I don't understand, though, is > the part about beamline staff not wanting to expose their users to > questionable software. Does this seem consistent with my observation > that modules often introduce breaking changes? I don't think it has to > do with testing because I think the author of the module tests any bug > fix or feature addition before making a new release. Even if the author > does not have the hardware, I think the author will at least confirm > that the fix or feature works for someone who does have the hardware > before making a new release. I don't want to belabor the point, but on > the one hand, Mark says he rarely sees breaking changes in modules, and > upgrading is straightforward; but on the other hand, your beamline staff > are worried about exposing their users to questionable software. What > am I missing? > > Regards, > > Lewis |