> > I wonder if a solution to this problem might be to provide some kind
> > of a version map file. Let's suppose that the map file is a bunch of
> > lines of the form X Y Z, where X, Y, and Z are version numbers. The
> > semantics could be: we (the extension authors) promise that if you
> > want to upgrade from X to Z, it suffices to run the script that knows
> > how to upgrade from Y to Z.
> > This would address Tom's concern, because if you write a master
> > upgrade script, you have to explicitly declare the versions to which
> > it applies.
>
> This would just move the problem from having 1968 files to having to write
> 1968 lines in control files,
1968 lines in one control file, is still much nicer than 1968 files in my
book.
From a packaging standpoint also much cleaner, as that single file gets
replaced with each upgrade and no need to uninstall more junk from prior
install.
> We maintain multiple stable branches (5, at the moment: 2.5, 3.0, 3.1,
3.2,
> 3.3) and would like to allow anyone running an old patched version to
still
> upgrade to a newer version released earlier.
>
> --strk;
>
> Libre GIS consultant/developer
> https://strk.kbt.io/services.html
That said, I really would like a wildcard option for issues strk mentioned.
I still see the main use-case as for those that micro version and for this
use case, they would need a way, not necessarily to have a single upgrade
script, but a script for each minor.
So something like
3.2.%--3.4.0 = 3.2--3.4.0
In many cases, they don't even need anything done in an upgrade step, aside
from moving the dial button on extension up a notch to coincide with the lib
version.
In our case, yes ours would be below because we already block downgrades
internally in our scripts
%--3.4.0 = ANY--3.4.0
Or we could move to a
2.%--3.4.0 = 2--3.4.0
3.%--3.4.0 = 3--3.4.0
Thanks,
Regina
