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?
