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: | Mark Rivers <[email protected]> |
To: | "'Mooney, Tim M.'" <[email protected]>, "Jemian, Pete R." <[email protected]>, "[email protected]" <[email protected]> |
Date: | Wed, 7 Feb 2018 17:32:17 +0000 |
I think it would be good to have 2 types of scripts: -
assemble_synApps_x_y.sh (or
install_synApps_x_y.sh). This would do a git clone, i.e. a fresh install. -
update_synApps_x_y.sh. This would assume that the tree already exists and just go into each module and do a git pull; git checkout y.z Or perhaps a single script that just checks to see if the module exists and does a git clone if it does not. How to handle different names people give the subdirectories? Require that there be a softlink called “asyn”, “calc”, etc. even
if the directory is asyn-4-33? Mark From: Mooney, Tim M. [mailto:[email protected]]
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. Tim Mooney ([email protected]) (630)252-5417 From: [email protected] <[email protected]> on
behalf of Mark Rivers <[email protected]> > There is such a script for synApps (last updated in October 2017):
|