Upgrade MapServer package to 5.6.1 release

[jmckenna]

Assefa,

I think we should upgrade to MapServer 5.6.1 now in OSGeo4W. If you don't have the time at the moment, I can take this on. Where are we with the status of ticket:4 - should I now be able to build MapServer and PHP/mapscript from the OSGeo4W libs? I think I should be able to use the makefiles from 'mapserver-5.2.2-2-src.tar.bz2 ' as guidance, correct?

-jeff

[assefa]

Jeff,

I had started but I will need to finish it. I will upload a new package tomorrow. I don't have my dev package on my current lapotop to work on it today.

[jmckenna]

Great, thanks Assefa.

[assefa]

Upgraded the mapserver package. In fact I created a mapserver56 package that uses gdal16: I am not sure if that is the best solution, but wanted to use a more recent gdal version (vs gdal1.5 that is used for the current mapserver). Would it be better to keep using gdal1.5 or use gdal 1.6 and remove older versions of mapserver?

[jmckenna]

Assefa/Frank,

I ran into this problem when giving an OSGeo4W demo/presentation at a conference recently: I couldn't find the MapServer 5.6.1 package to upgrade.

I see now that there is a new package entirely for this release ("mapserver56").

I think having 3 MapServer packages is unacceptable for users. Here is a summary of existing MapServer OSGeo4W packages:

• "mapserver" --> contains 5.2.2 release
• "mapserver-dev" --> contains 5.2 betas
• "mapserver56" --> contains 5.6.1 release

I am requesting that we have only one package, named "mapserver". Having 3 packages is confusing to new users.

I would prefer removing older versions, to make it easier for users. I think this issue is related to upgrading GDAL, which I have requested/filed in ticket:149

Does anyone have a problem with only having one MapServer package for OSGeo4W from now on? (maybe we can remove the dev package now, and only use it around the time of beta/rc releases, when feedback is needed from testing)

Thoughts?

-jeff

[assefa]

Jeff, I did indicate that I created a 5.6 package in this bug but did not get comments until today.

I am not sure what the best solution is but we just need to define it and stick with it, maybe something like:

• always use the current gdal for the builds (in this case I should have just built the 5.6.1 against gdal1-5
• when we decide to upgrade to a new gdal version, move older versions somewhere else (I still believe having few older versions is important for users) and have in the mapserver package a version using the new gdal

I also believe, there is nothing wrong having mapserver-dev, It is just not up to date now but It is very useful for new upcoming features.

I think the confusion comes in this particular case came for the mapserver56 package, but if we make sure the mapserver package has always the latest, would it still be confusing to users?

[warmerdam]

One problem with upgrading MapServer to a new version is that there are independent packages, such as Python MapScript, that depend on the MapServer ABI. In fact, I think Python MapScript has been broken for more than a year because Assefa upgraded the original MapServer package to an ABI incompatible version without making arrangements with me.

With GDAL the practice is to have a distinct package for each ABI version (1.5, 1.6, 1.7). The alternative is to break almost everything on the system till all dependent packages are upgraded.

In the case of MapServer it should be less of an issue. We would just need to ensure that the web applications work with the new mapserver, and rebuild a few closely related packages that depend on the ABI (ie. the various MapScripts).

We offer users a guarantee of stability and we have to be very cautious about changing packages in a way that a routine update will start breaking things. Even a MapServer update to a new version is likely to do this.

So, on reflection, I think major new versions of MapServer ought to be distinct packages.

This also comes back to thinking about an OSGeo4W "reboot" where we pick new versions for base packages including MapServer, GDAL, Python, etc.

[assefa]

Jeff, any comments on this?

I am willing to do cleanup and make sure that things are up to date and working but would like to know if we go with one mapserver56 package (and additional 56 packages for mapscript flavors) or do I put the back the release in the current mapserver package and wait for a 'reboot' to do any upgrades using new GDAL.

[jmckenna]

Assefa,

I think the "mapserver" package should always contain the latest MapServer release. (I feel that this is the easiest for users)

However it seems GDAL has a new named package for each release. So I am confused as to what we should do for the MapServer package.

I do feel that all packages should follow the same guidelines, which we will establish for the OSGeo4W 2.0 release (reboot), as Frank mentioned. By the way, proof of this is the QGIS package - I *cannot* understand what package to use, there are just too many different packages to pick from.

For now is it ok if the "mapserver" package contains the latest release? (is this easy for you?) I am in for whatever is easier for you to maintain.

Thanks.

-jeff

[jef]

Replying to jmckenna:

I do feel that all packages should follow the same guidelines, which we will establish for the OSGeo4W 2.0 release (reboot), as Frank mentioned. By the way, proof of this is the QGIS package - I *cannot* understand what package to use, there are just too many different packages to pick from.

Why not? QGIS has two lines of releases: 1.0.x with "long time support" and 1.x (with x>0) for the cutting-edge releases.

So in OSGeo4W we have the 1.0.x line of releases with long time support (qgis: Quantum GIS (LTS release), a line 1.x line of releases for the releases of ongoing work (qgis-unstable: Quantum GIS (cutting-edge releases)) and nightly builds (qgis-dev: Quantum GIS nightly builds of the trunk).

If you select the QGIS express target, you get qgis-full which is 1.0 with all optional dependencies like python and grass.

[jef]

meanwhile mapserver is at 6.4.1.