mCtrl Release Process

This page briefly describes the release process of new mCtrl versions.

Test Build

Prior the release, it has to be tested that mCtrl can build at least in these environments:

MSYS + mingw-w64 + Make

     $ cmake -G "MSYS Makefiles" path/to/mctrl
     $ make

MSYS + most recent version of MSVC:

    $ cmake -G "Visual Studio 12 2013" path/to/mctrl

or to build 64-bit mCtrl version

    $ cmake -G "Visual Studio 12 2013 Win64" path/to/mctrl

Then just open the generated solution and build within the MSVC IDE.

Further Notes

When built with mingw-w64, MCTRL.DLL is linked against MSVCRT.DLL in order to not add extra dependencies. MSVC does not support this as C runtime library of the given MSVC version is used. Therefore with MSVC, mCtrl uses static C runtime library.

Build Correctness

After the build with any given tool-chain is performed (especially if the build was done in any new version of a toolchain or different then commonly used tool-chain), some quirks of the build need to be verified, as they tend to break under such circumstances:

• String resources must be zero terminated. RC.EXE from MSVC by default strips any trailing zero terminators even when explicitly specified. Other resource compilers may have similar gotchas.
• Symbols exprted from MCTRL.DLL should strictly use stdcall calling conventions and no decorations. E.g. there has to be an exprted symbol mcChart_Initialize but not _mcChart_Initialize@0.

When building mCtrl, test_build.exe is also created. You may use this tool to test these issues.

Testing

At least small sanity testing should be performed on as many Windows versions as possible. In particular, these should be taken into account:

• Windows 2000:
  • It is the oldest supported Windows version.
  • MSVCRT.DLL is quite limited in many aspects. Especially the secured variants of many standard functions are not available.
  • GDIPLUS.DLL is not part of clean system. To test some mCtrl parts, redistributable version from MSDN has to be placed in the same directory where the MCTRL.DLL lives.
• Windows XP:
  • First Windows version using visual themes (UXTHEME.DLL). Both themed and unthemed painting has to be tested. The default visual styles theme is called Luna.
• Windows Vista/7:
  • mCtrl uses Direct2D here instead of GDI+ for the chart and image view controls.
  • Completely new visual styles theme (Aero).
• Windows 8/8.1
  • Completely new visual styles theme (I don't know name, but it follows the flat look hype).

Furthermore, the HTML control heavily depends on installed MSIE version. AFAIK, the oldest possible version is 5.01 (on vanilla Windows 2000). Its support for JavaScript and many modern web technologies is close to none or none.

Release

After all tests are ok, the release process should follow these instructions:

• Make the source and binary packages with the script scripts/release.sh. The script has to be run within bash shell (MSYS or MSYS2) and expects mingw-w64 and GNU Make or ninja installed. Additionally it need zip or 7z available in the path. Run it from root mCtrl directory:

    $ cd path/to/mctrl
    $ scripts/release.sh

The script executes the builds in a temporary directory (it does git checkout so only committed stuff is visible) to not pollute the project directory tree. It only drops the final output files into the mCtrl directory:

• mCtrl-X.Y.Z-bin.zip (binary package)
• mCtrl-X.Y.Z-src.zip (source package)
• build-XXX.log (build logs)

After a short review everything is OK, the release tag should be committed into the git repository and provided upstream:

    $ git tag -a 'release-X.Y.Z'
    $ git push --tags

Finally we need manually upload the packages to sf.net and http://mctrl.sourceforge.net/ should be actualized (news, high level change log, new documentation.)