[mapguide-internals] Re: 2.1.0 Final Windows Installer

Gabriele Monfardini gabrimonfa at gmail.com
Sat Nov 21 07:50:07 EST 2009

>The 2.1 branch has been effectively frozen since June.  As far as I know,
> the only submissions made to that branch have been specific to bug fixes
> http://trac.osgeo.org/mapguide/log/branches/2.1/MgDev.
> MgDev/trunk has always been the active development stream.
> We only branch when we are getting close to a release.  And yes, trunk does get broken occasionally.

Ok, thank you. I've missed the trunk version in the code browser-

> Most of the third party stack is not available on Windows so we include it in the source tree.

I undestand your point.
My question is: are software in the third part stack very customized
for Mapguide or not?

And if not (but I don't know, obviously), we're not really versioning
that code. We only need the source code (maybe in a particular
version) to be in a certain directory plus some small modifications.

For example, let think from now on to one of this third part software, PHP.

Would be viable to point to php 5.2 stable release and add a
customized php.ini (as is done with the provider list in Oem/FDO)?

This way we should benefit from bug fixing from PHP guys.
If developers find that a certain release is no more compatible with
mapguide, they can simply point to the last release that is
"Users beware: PHP latest release (5.x.x) is not fully compatible with
our code. While we're working on it, please use version 5.y.y instead
to build mapguide".

For lazy users, PHP code may remain as now, even in a
"not-always-up-to-date" version, but it is important that I may opt to
not download it and use current version.

I think that maintaining "mapguide-PHP" up-to-date with PHP releases
is overwhelming for you and, in the end, not the best way to use
project resources.
Testing new releases and report problems can be done by the community,
and we should collaborate with PHP guys if we found regressions, bug
or simply incompatibilities with our code in newer PHP versions.

Maybe building the code from the source would be a little more
complicated to setup than now.
But I don't think that the average windows user Joe would build from
the source code anyway, since the bar is already high if you're not a
Only developers would hit the small penalty (to have to download
elsewhere PHP and apply some patches) but also to obtain the big
advantages (not to have to maintain it).

As a first step (since I know that proposing is easy, realizing
require a lot of work) it would be useful just to keep track of exact
version numbers used for all third party software, and if
Mapguide-only modifications are, in your opinions and as a rule of
thumb, small or big.
This would enable we all to choose the easiest candidates to play with.

I want to emphasize again that I'm not asking you to do the ugly work,
but only discuss a way to enable users to contribute easily to the
project,doing the ugly work :)



More information about the mapguide-internals mailing list