Shouldn't GEOS 3.1 branch be bumped to 3.1.2

[robe]

I'm almost ashamed to be complaining about this, but it just occurred to me that the last release of geos for 3.1 we did was for 3.1.1 on June 15th 2009.

When building the PostGIS 1.4.1SVN binaries for windows, it occurred to me that my GEOS is still reading 3.1.1 and I'm thought I was using 3.1 branch.

Shouldn't we change this to 3.1.2 or better yet 3.1.2SVN to minimize on confusion with the actual last released branch version?

[pramsey]

We have not used this process in the past, as almost nobody uses svn versions in settings where they might become confused. Basically, version numbers are a deployment concern, not a development concern. The version number is not bumped up until the release process.

[robe]

So I guess I should not be releasing these as part of the PostGIS 1.4.1 experimental releases. That was how this became an issue for me.

I guess to me - at least now, this is a testing concern which I would think would be a development concern.

I was packaging GEOS 3.1 just fixes with 1.4.1 just fixes so that people who are having problems fixed by either -- can test out the changes without being forced to run a more unstable release. They could take the new GEOS 3.1 (say if they are running 1.3 or 1.4.0 RTM), the new PostGIS 1.4.1SVN or both. With PostGIS I can tell, with GEOS I can not.

Now that I can't tell the difference between those running 3.1.1 RTM and 3.1 stable non-RTM, this will become a bit confusing from a testing standpoint.

[pramsey]

Committed to branch 3.1 at r2721 and trunk at r2720.

[pramsey]

Reversed the upgrade process a bit, bump up revision numbers *after* release so that the repo version is always one higher than the release version.

[strk]

Milestone 3.1.2 deleted