Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Thu, 8 Feb 2018 19:24:59 +0000

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System