> 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?
>
Minor correction scripts to get from 3.2.0 to 3.4.0 would be:
postgis--3.2.2--3.3.0.sql
postgis--3.3--3.4.0.sql