> > 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