Opened 3 years ago
Last modified 3 years ago
#5166 closed defect
Remove Micro (Patch level) from our extension scripts — at Version 3
Reported by: | robe | Owned by: | strk |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 3.3.0 |
Component: | build | Version: | master |
Keywords: | Cc: |
Description (last modified by )
This will be for PostGIS 3.3.0 moving forward. We discussed the idea of doing that for all minors, but decided that was too drastic.
So sadly we've still got to carry all those scripts.
3.3 will have scripts
# these all 0 byte postgis--3.0.0--3.3.X.sql postgis--3.0.1--3.3.X.sql : postgis--3.1.0--3.3.X.sql postgis--3.1.1--3.3.X.sql postgis--3.1.2--3.3.X.sql : : postgis--3.2.1--3.3.X.sql postgis--3.3.0alpha1--3.3.X.sql postgis--3.3.0dev--3.3.X.sql # these not 0 byte postgis--3.3.X--3.3.sql postgis-3.3next--3.3.sql postgis-3.3--3.3next.sql
(the 3.3next 3.3.sql I am thinking if we decided we want our alter extension scripts to have CREATE OR REPLACE only for existing and CREATE for net-net new, we'd still keep the CREATE OR REPLACE for the 3.3next even for net-net new and for the 3.3X—3.3.sql this would be CREATE for net-net new functionality.
and so most we will use 0 byte files as Paul proposed here - https://trac.osgeo.org/postgis/wiki/PostGISExtensionPaths#SOLUTION3
postgis 3.4 would then look like
# these all 0 byte postgis--3.0 : postgis--3.1.0--3.4.X.sql postgis--3.1.1--3.4.X.sql postgis--3.1.2--3.4.X.sql : : postgis--3.2.1--3.4.X.sql postgis--3.3--3.4.X.sql #regardless which 3.3 micro release, no new files # these not 0 byte postgis--3.4.X--3.4.sql postgis-3.4next--3.4.sql postgis-3.4-3.4next.sql
Change History (3)
comment:1 by , 3 years ago
Summary: | Remove Minor from our extension scripts → Remove Micro (Patch level) from our extension scripts |
---|
comment:2 by , 3 years ago
comment:3 by , 3 years ago
Description: | modified (diff) |
---|
Is there a typo in the original description of this ticket ? I don't understand the
postgis--3.0
line, and I see spaces before the--3.4.X.sql
which I'm not sure how to interpret.Also, I think Paul idea was to have upgrade scripts look like:
I don't see the benefit of having an upgrade path called
3.3.X--3.3.0
otherwise (would look like being open for downgrades) ?How does this simplify things ? What problem does it solve ?