Experimental Physics and
Industrial Control System

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