Experimental Physics and
Industrial Control System

synApps is intended to be upgraded in place between releases, and contains software (makeReleaseConsistent.pl, release.pl) to support that practice, because that has been a convenient way for us to stay current with all the disparate development efforts (base, seq, asyn, motor, autosave, etc.) on which  synApps modules depend.  The fact that a synApps release is not compatible with a version of base released two month later doesn't in my mind invalidate the entire effort to identify and assemble collections of software that work together.

When only one or a few module-version changes are needed to produce a working collection, I think it's not time for a new synApps release, because the upgrade-in-place strategy handles that well.  But when a module on which many other synApps modules depends changes, then upgrade-in-place becomes impractical, and a new synApps release is needed.

This strategy has worked pretty well, I think.  In my 20+ years of running synApps on our beamlines and labs, I have always been able to run an official synApps release, and I have also been able to make module-version changes needed by one beamline without exposing other beamlines to any risk.  In this way, the new module version gets tested at only the beamline that expects to benefit from it.  Once vetted, that module version presents less risk for inclusion in the next version of synApps.

This vetting of individual modules in older releases of synApps is important, because it's more efficient and thorough to test  software with the hardware on which it's intended to run, and we don't own that hardware.  We have no beamline at our disposal for testing.  The only way we can test with hardware is to persuade a beamline to upgrade, and we persuade them by exposing them only to the new software they've told us they want.