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" #endif
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.
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|
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