Here are my thoughts of how this can work to satisfy our specific needs and
that of others who have many micro versions.
1) We define an additional file. I'll call this a paths file
So for example postgis would have a
postgis.paths file
The format of the path file would be of the form
<version pattern1>,<version pattern2> => 3.3.0--3.4.0
It will also allow a wildcard option
% => ANY--3.4.0.sql
So a postgis.paths with multiple lines might look like
3.2.0,3.2.1 => 3.2.2--3.3.0
3.3.% => 3.3--3.4.0
% => ANY--3.4.0
2) The order of precedence would be:
a) physical files are always used first
b) If no physical path is present on disk, then it looks at a
<component>.paths file to formulate virtual paths
c) Longer mappings are preferred over shorter mappings
So that means the % => ANY--3.4.0 would be the path of last resort
Let's say our current installed version of postgis is postgis VERSION 3.2.0
The above path formulated would be
3.2.0 -> 3.3.0 -> 3.4.0
The simulated scripts used to get there would be
postgis--3.2.2--3.3.0.sql
postgis--3.3.0--3.4.0.sql
This however does not solve the issue of downgrades, which admittedly
postgis is not concerned about since we have accounted for that in our
internal scripts.
So we might have issue with having a bear: %. If we don't allow a bear %
Then our postgis patterns might look something like:
3.%, 2.% => ANY --3.4.0
Which would mean 3.0.1, 3.0.2, 3.2.etc would all use the same script.
Which would still be a major improvement from what we have today and
minimizes likeliness of downgrade footguns.
Thoughts anyone?