[GRASS-dev] GRASS extensions/addons mismatch

[Hamish]

Hamish:
> > btw, my current feeling about the
> > ~/.grass$MAJOR/addons$MAJOR.$MINOR.$BUGVER
> > specific path to protect from binary GIS_H incompatibility is that it
> > may be better to create a ~/.grass65/ in addition to ~/.grass64 to keep
> > the two separate.

Martin wrote:
> do you mean also to separate config files, eg. wxGUI settings? Then
> you would have eg. .grass64/wx and .grass65/wx.

that would be a downside to this idea, yes. but on creating a new dot-
dir it could check for version-1 dot dir and copy the config file over.
I am not proposing this as a perfect solution, it's just an idea to
throw around. e.g. it may well be that polluting the home dir with more
dot-dirs is considered more offensive than having per-version dirs within
~/.grass6/.  shrug.

In retrospect it may be a silly idea since only developers (who can clean
up their own messes) will have 6.5svn installed, so no point in uprooting
all 6.4.x users for the sake of them.


> Unfortunately this layout doesn't allow to have installed
> extensions
> eg. for 6.4.2 and 6.4.3 or 6.4.2 and 6.4.3svn, you would
> end up with the same mismatch (expecting than extension will be
> installed in `.grass64/addons`).

presumably the user would only have a single operational 6.4.x version
installed and would monotonically upgrade to only newer versions, and
rebuild any C module which complained. (perhaps with a
g.extension.rebuild.all wrapper script) Those using self-build svn copies
and developers bouncing between versions would be left to manage their
own rebuilds as needed. In practice I find I only use a single version
for my real work, and all the version swapping is just done for
development and testing, so even through I use addons a lot and only a
single addons dir, GIS_H has never actually been a problem for me.


> I think that `~/.grass$MAJOR/addons$MAJOR.$MINOR.$BUGVER` is more
> flexible approach.

I don't mind that so much, just exploring possibilities.


> It's blocker for 6.4.2 (since you have asked RC3 for
> `g.extension` even it's not *really* ready,

it is not mature as it one day will be, but AFAIK it is not defective
in any way. What does "really ready" mean to you?

release requirements:
- it basically works
- the code we release has been tested

I don't mind so much if it is not "feature complete" for 6.4.2, as that
is a somewhat endless goal.


I still think that tagging a final rc3 before release is a good idea,
even if the gap between that and the final release is only a week or so.
"If no problems are found this will essentially be the same as the final
release"

I'm happy with the feature set we have in 6.4svn right now. We can make
further improvements and backports for 6.4.3, sure..


btw, backport r49743 to 6.4?
 https://trac.osgeo.org/grass/changeset/49743


Hamish