I saw in the trac logs that a RC build had been posted via the release notes
(though not officially announced). First couple of observations:
* The install implies a side-by-side could be deployed with 3.1 as it is
not advertised by the installer as a patch or repair and I get to choose new
folder, ports, app pool and service names. However the service looks to
still be called "MapGuide 3.1" in the windows services.msc manager (or did I
* Is there a reason the installer's first action is to install MSVC C++
2012 runtime? Is this an installer dependancy that can be updated? I think
all the MG and third party components are built by a much newer C++.
I'm pretty sure it was spelled out in the release notes, but windows
installer has never been tested for a side-by-side install, whether it's
between major releases or between patch releases of the same major.minor
version. The instant setup bundle is the preferred method if side-by-side
installation is desired. It's for this reason that services and app pool
names retain the same major.minor versions between patch releases.
We still install MSVC 2012 runtime as we are still using bundled versions of
PHP and Apache httpd that were built with MSVC 2012. This is because no
version of PHP5 built with MSVC 2015 is available, the only official PHP
binaries that are built with MSVC 2015 is PHP 7 and that is still a no-go
for us because we cannot generate PHP7-compatible bindings with our copy of
SWIG. This is a problem that we must solve eventually as PHP 5.6 will be
end-of-life in December this year.
Although MapGuide is built with MSVC 2015 it integrates with PHP and Apache
through C interfaces, so things should be safe.
I'm sure side-by-side would work with the service renamed to 3.1.1 -- but
that's up to you as lead.
I do still think it is an oddity to have a point release that the installer
doesn't recognise as a patch update or requests that the previous version is
uninstalled first (create MGP of everything etc). Most folk are smart, but
a little thing could help those that are not, or just think they are (like
Reading the release notes, I should do that *properly*
If sticking with the current approach (which is fine), move the "Installer notes" to the very top of the release notes (they are buried some way down) and say that before uninstalling 3.1, use Maestro to back up any projects as package files.
I've moved installer notes up as per your suggestion.
Making the windows installer handle upgrades of previously installed
versions is a solve-able problem, but there's bigger fish to fry in the
grand scheme, especially with the limited developer resources we have. I
rather spend resources on having feature X, Y and Z implemented rather than
having to relearn WiX and MSI (ugh!) to handle a situation that can be
easily worked around with a simple <uninstall existing version + install new