Nat! bio photo


Senior Mull

Twitter Github Twitch

Prerelease thoughts Part IV: Project

Continued from Prerelease thoughts Part III: Packages



Each library should check in its envelope header, that the version of other mulle projects it depends upon are up to date.

For example the mulle-objc-runtime checks the mulle-vararg version with.

#if MULLE_VARARG_VERSION < ((1 << 20) | (0 << 8) | 11)
# error "mulle-vararg is too old"

This is all hand-written and not properly maintained. I will try to automate this with a script for the next release. This should improve the quality and reduce time spent on headers.


For each release all projects get a mulle-sde upgrade. This installs new files into the share directories such as cmake/share. A subsequent reflect may generate different headers, after all there is constant progress. Consequently the version number needs to be bumped.

This is an automated process, where I have a list of repositories and simply say something like:

shell-all mulle-sde upgrade
shell-all mulle-project-version ++
shell-all git add -u

Nevertheless, a release at the moment touches all projects. Eventually I would prefer to disassociate, say, mulle-c from MulleWeb. So that I can push out a mulle-c release without affecting MulleWeb.

Mulle Libraries

So far all projects are pulling “latest” (or “prerelease-latest”). In actual development it doesn’t really matter to me, as the dependencies are symlinked locally (automatically).

As parts of the project is still fairly volatile, tracking version changes manually over a dozen of projects isn’t enticing. So in the same way that header version checks will be maintained, there could be another script that updates the version information in the sourcetree config.

mulle-fetch has a tags filter to grab archives within version ranges, which could be used for semver checks like ‘>= 1.0.0’ but I haven’t used it so far.

Third party libraries

So far third party libraries haven’t been giving me much trouble. And the list of third party libraries is small:

Project Third Party Library Style Comment
mulle-http http-parser Stolen Unmaintained (alternatives?)
MulleCivetWeb civetweb Clone Stable
MulleCurl curl Clone Stable
  openssl Clone Outdated branch
MulleHoeDown hoedown Clone Stale (good)
MulleObjCExpatFoundation expat Clone Stable
MulleObjCJSMNFoundation jsmn Clone Volatile (fork?)
MulleZlib zlib Clone Stale

The effort to keep them up to date is unavoidable, but so far has been minuscule. I look up the latest version on the respective homepage and manually update the version numbers in the sourcetree config and that’s it. For example in MulleObjCExpatFoundation I upgraded to a newer version with:

mulle-sde dependency set expat tag OpenSSL_1_0_2u

Some of the third party code might need replacements in the future, such as the http-parser.

If I were to use versioning properly in my sourcetree config files I could write something like ‘>= 1.1.10 && < 2.0.0’ and that would decrease the amount of work I have to do on keeping third party version numbers straight.


The release process took way too long. In these prerelease thoughts I surveyed and explored, what I did and will do to improve the release process:

  • ditch binary content in apt repositories
  • ditch homebrew formulae for binaries
  • ditch ubuntu version fragmentation and go with debian versions
  • generate version checks for C headers automatically
  • possibly use semver instead of just “latest” for dependencies
  • ditch mulle-clang and write mulle-cc

Post a comment

All comments are held for moderation; basic HTML formatting accepted.

E-mail: (not published)