[postgis-devel] Extension Versions

[Paul Ramsey]

OK, looking at this, the Makefile seems to drive of the .control file
for versions, mostly (but not entirely), is the control file used in
the extension itself or just in the build? If the latter, I'd propose
removing it and having the version information written into the
Makefile in a Makefile.in -> Makefile process per usual.

Secondly, looking at some entries i the Makefile, I see more version
strings, for the minor upgrades... this seems less that lovely, and
could be a pain to automate.

sql/$(EXTENSION)--2.0.0a11--$(EXTVERSION).sql:
sql_bits/postgis_raster_upgrade_minor.sql
	cp $< $@


Finally, this entry disturbed me because it is pulling .in and .in.c
files into a .sql file, which seems dangerous at best. Why is it doing
this/?

sql_bits/postgis_raster_upgrade_minor.sql:
../postgis_extension_helper.sql sql_bits/remove_from_extension.sql.in
../../postgis/postgis_drop_before.sql.in.c
sql_bits/postgis_upgrade_minor.sql
	sql_bits/rtpostgis_upgrade_20_minor.sql
../../doc/raster_comments.sql  ../../doc/postgis_comments.sql
../postgis_extension_helper_uninstall.sql
	cat $^ > $@



On Sun, Jan 8, 2012 at 11:53 PM, Paragon Corporation <lr at pcorp.us> wrote:
>  Paul,
>
>
>
>> Sent: Monday, January 09, 2012 1:37 AM
>> To: postgis-devel at postgis.refractions.net
>> Cc: Paragon Corporation
>> Subject: Extension Versions
>>
>> Reading the HOWTO_RELEASE and looking at the versions
>> referenced therein, I see:
>>
>> in postgis.control
>>   default_version = '2.0.0.a14'
>>   module_pathname = '$libdir/postgis-2.0'
>>
>> in postgis_topology.control
>>   default_version = '2.0.0a14'
>>   module_pathname = '$libdir/postgis-2.0'
>>
>> So, two questions:
>>
>> First, would it make sense to bring these files into the
>> autoconf process so they simply get the versions directly
>> from the Version.config file?
> I was hoping someone would offer since most of the whole pgconfig stuff is
> greek to me.
> That works for me.
>
>> Second, there are two version schemes above. Could we use
>> stick with a three-component system, as topology.control uses?
>> Third (of two), are there any downsides if we push
>> Version.config up to 2.0.0a17 or some other nice high number
>> and then keep on incrementing as we push out interims?
>>
>> I'd like to do all of the above it it won't destroy things.
>>
> Drats that was a typo (corrected) -- they both follow the 2.0.0a14 format.
>
> I was thinking that the whole a14 etc thing can go.  And when we finally
> release tagged releases they would follow
>
> 2.0.0alpha1  or 2.0.0alpha01  etc.
>
> Take your pick.  I would just need to add a final migration path to take a
> user from the last
>
> .a1..  to alpha1 or whatever versioning scheme name we want.
>
> Right now all the upgrade scripts are pretty much copies of each other so I
> just create them as a convenience
> as people could easily copy one name it e.g
>
> postgis-2.0.0a14--2.0.0alpha01
>
> to bring themselves up to the first alpha.
>
> Thanks,
> Regina
>
>