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

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 robe, 3 years ago

Summary: Remove Minor from our extension scriptsRemove Micro (Patch level) from our extension scripts

comment:2 by strk, 3 years ago

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:

`postgis-3.1.1—3.1.MAX.sql' or similar ?

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 ?

comment:3 by robe, 3 years ago

Description: modified (diff)
Note: See TracTickets for help on using tickets.