Tim wrote: > I question when looking at : > http://trac.osgeo.org/grass/browser/grass-addons > > I wonder: > * why is there a separate branch per major grass version?
between grass 5, 6, and 7 the library APIs change and the module options/flags change, so a module written for one often won't work on another without some slight modification. > * what is the policy for backwards / upwards compatibility? within major version backwards compatibility. A module written for 6.0.0 will still work with any future 6.y.z versions. It is likely for compiled modules the ABI is not stable, and you will have to recompile for the current version. Any python and shell scripts should be forward-compatible though. If you try to run a compiled addon module against a different libgis than the one it was built for, you will get the "please untangle versions" error. "g.version -r" shows the libgis rev for this reason: g.version -r: Print the GIS library revision number and time GRASS 6.4.1 (2011) Revision: 43636 Date: 2010-09-22 22:18:42 +0200 (Wed, 22 Sep 2010) GRASS 6.4.2 (2012) Revision: 45934 Date: 2011-04-13 13:19:03 +0200 (Wed, 13 Apr 2011) GRASS 6.4.3svn (2013) Revision: 50937 Date: 2012-02-26 02:14:51 +1300 (Sun, 26 Feb 2012) GRASS 6.5.svn (2013) Revision: 50936 Date: 2012-02-26 02:14:47 +1300 (Sun, 26 Feb 2012) it doesn't change very much, but often enough to mean that you need to recompile your addons when switching between minor versions. (e.g. it's been more than a year since it changed last) > * shall we instead of grouping by command type group by > version? an addon package containing grass7 addons should exclusively depend on the grass7-core package etc. so at minimum it must be grouped by major version. Hamish: > > and install to /usr/lib/grass64/addons/. We'd have to > > patch our lib/init/init.sh in the main ubuntu package > > to add that dir to the GRASS_ADDON_PATH if it existed > > on the system. Tim: > Why do we not make this default, then? because Debian installs grass in a funny place (/usr/lib/grassXY), any system packages need to be available to all users equally- so in a common OS dir, and personal addons can't go into a system dir where the user does not have write access. It's not a big deal to do the patch. regards, Hamish _______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user