[postgis-devel] autobuild cleanup

[Kevin Neufeld]

Ok, so, it sounds like we have several different use cases.  If, for 
some reason, folks are really, really interested in getting the latest 
branch (docs or JSON enhancements) rather than going straight to SVN 
head, then we're going to have to post 3 different builds.

1. Last tagged static release 1.3.3
- docs at http://postgis.refractions.net/documentation/manual-1.3/
- download at http://postgis.refractions.net/download/postgis-1.3.3.tar.gz

2. Last current branch release 1.3.4SVN
- docs at http://postgis.refractions.net/documentation/manual-1.3.4svn/
- download at 
http://postgis.refractions.net/download/postgis-1.3.4svn.tar.gz

3. Current SVN head 1.4.0
- docs at http://postgis.refractions.net/documentation/manual-svn/
- download at http://postgis.refractions.net/download/postgis-svn.tar.gz

Alternatively, we don't provide option #2 and leave it to users to get 
the branch version themselves from svn.  But then, the question remains, 
if we build the docs from the branch, do we leave the branch version 
1.3.4 and purposely break the download urls in the documentation? (It 
would have to be 1.3.3 for it to work ... but as Mark pointed out, this 
gets confusing when reporting bugs).

Mark Cave-Ayland wrote:
> I strongly disagree with this, because if we make a 1.3.4-named tarball
> available, then people will start using it as if it is a new release.
> Otherwise we will have people reporting issues against 1.3.4 ("I installed
> it from postgis-1.3.4.tar.gz, honest") when in fact it is a SVN
> pre-release containing potentially harmful bugs.
> 
> On a similar note, I noticed a while back that Paul changed the release
> number in Version.config to remove the SVN suffix from REL_MICRO_VERSION.
> The reason for this is so that if someone does a "SELECT
> postgis_full_version()" then we know if someone is really using the proper
> 1.3.4 release whenever it appears, rather than a 1.3.4 pre-release.
> Therefore if we are going to start encouraging people to use pre-release
> versions then we really need to put this back in as it will save us a
> whole lot of support heartache further down the road.
> 

Mark, doesn't the 1.3.4 version mean that it's coming from the branch? 
Why does it matter if we have the SVN suffix?  I could see this need if 
we were to use 1.3.4 for svn head instead of 1.4.0.

-- Kevin