postgis_scripts_installed / postgis_scripts_released are screwy

[robe]

Okay guys I begged you to make an alpha release so we can hve point in times to verify where people are and now all I have to know what's up are these two functions and I come to find that these aren't even working.

Is this just my install or are they really broken?

In 1.5 I can do this:

 select postgis_scripts_installed(), postgis_scripts_released();

I get this:

 postgis_scripts_installed | postgis_scripts_released
---------------------------+--------------------------
 1.5 r7360                 | 1.5 r7360

I do this in PostGIS 2.0 and I get something less than useful.

 postgis_scripts_installed | postgis_scripts_released
---------------------------+--------------------------
 2.0 r                     | 2.0 r

[strk]

I think the whole installed/released thing should be rethought so to advertise the _last_ change in the SVN branch, rather than the last change in the file itself.

This is because the file itself includes other files so a change in an included file may not be seen at all.

Moreover, the SVN revision thing should be part of the postgis version itself, found somewhere maybe in Version.config to unify the view on the matter.

@robe: next time do your tests before pushing for a tag :)

[robe]

I think the perl script scans other includes .sql files. well it used to before anyway and the reason it was based on files is that before not all micros required upgrade of sql or at least that was the thinking.

strk -- I really have no time to test without a tag. No tag NO TEST. This perfection thing has gone on long enough. It's as simple as that. At least with the version.config (if we have an alpha) thing I have some clue what I'm testing. I don't now. If we released an alpha when I WANTED one, I could even do a make check and we'd be all ready for an alpha2 right now (whic is about where we should be). As it stands I can't test anymore even if I wanted to since the make check stuff is completely broken for me.

[pramsey]

Should be less screwey now. r9122

[pramsey]

The question remains as to whether to use the global SVN revision. The downside of that is we would be asking for script updates at times when they aren't really required (the scripts in fact have not changed between releases). The upside would be something like strk said on ensuring we are really reflecting the state of all possible components (though we could do that by just updating the utils/read_scripts_version.pl to pull in absoluately all dependent script files.