[postgis-devel] Objects versioning

[Paragon Corporation]

I guess there is no point in voting

+1 

at anyrate.  Since extensions would require upgrade for each minor to stamp
correctly and we have more plpgsql functions than ever,
I guess my dream of not always having to upgrade the database will never be
anyway.  That was the main reason for not always updating the script version
with each release. 

> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net 
> [mailto:postgis-devel-bounces at postgis.refractions.net] On 
> Behalf Of Chris Hodgson
> Sent: Friday, February 24, 2012 1:40 PM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] Objects versioning
> 
> Sounds good to me as well, I'm just hoping that the version 
> gets copied into each of those places from one config file 
> somewhere, using configure or autogen or some other manner of 
> automated substitution?
> 
> Beyond that I'm +1.
> 
> Chris
> 
> On 12-02-24 06:32 AM, Paul Ramsey wrote:
> > I can live with it, I'm pretty sure.
> > +1
> >
> >
> > On Fri, Feb 24, 2012 at 2:33 AM, Sandro 
> Santilli<strk at keybit.net>  wrote:
> >> I think it is time to simplify and improve robustness of 
> versioning.
> >>
> >> The current situation is weak in that there's no version 
> >> stored/checked inside the raster library nor in the raster 
> or topology scripts.
> >> Also the current version stored/checked for core lib/scripts isn't 
> >> necessarely correct because it relies on SVN keyword substitution 
> >> performed on the main file and thus doesn't catch modifications 
> >> happening in included files. Not to mention that under git-svn the 
> >> keyword substitution doesn't happen...
> >>
> >> I've created a ticket for this:
> >> http://trac.osgeo.org/postgis/ticket/1608
> >>
> >> But it's probably better to discuss on the list first.
> >> My proposal is as follows:
> >>
> >>   1) PostGIS has a single version for all components.
> >>     Such version is Major.Minor.Micro plus an optional
> >>     revision number (for SVN snapshots)
> >>
> >>   2) The PostGIS single version should be stored in all
> >>     libraries (core,raster) and user-facing scripts
> >>     (postigs.sql, rtpostgis.sql, topology.sql).
> >>
> >>   3) Each script should expose function to report
> >>     the version it embeds. Scripts bound to libraries
> >>     should also expose a function to report the version
> >>     of the bound library (core, raster).
> >>
> >>   4) The postgis_full_version() should check for the
> >>     version reported by all the functions as being equal
> >>     or suggest appropriate action to fix any discrepancy.
> >>
> >> The worst case I can see with this approach is that people are 
> >> requested to run the "upgrade_minor" script more often 
> than otherwise 
> >> needed, but I see absolutely no harm in doing that, as long as our 
> >> "upgrade_minor" scripts are working.
> >>
> >> I'd like to get this done before beta, so please cast your votes !
> >> Thank you.
> >>
> >> --strk;
> >>
> >>   ,------o-.
> >>   |   __/  |    Delivering high quality PostGIS 2.0 !
> >>   |  / 2.0 |    http://strk.keybit.net - http://vizzuality.com
> >>   `-o------'
> >>
> >> _______________________________________________
> >> postgis-devel mailing list
> >> postgis-devel at postgis.refractions.net
> >> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> > _______________________________________________
> > postgis-devel mailing list
> > postgis-devel at postgis.refractions.net
> > http://postgis.refractions.net/mailman/listinfo/postgis-devel
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>