Optizelle V1.2.2 Released

New Minor Release of the Optizelle Code and an Explanation of Our Release Process

Posted by Joseph Young on Thu, Apr 23, 2020
In Software under Optizelle

Today, we’re pleased to announce a new release of Optizelle v1.2.2. Our goal with this release is to update Optizelle to use current versions of its dependencies as well as ensure that we’re fully compatible with new versions of Python, MATLAB, and Octave.

Similar to our last release, some time has passed between versions. In order to better understand why, let us elaborate on what is required for an individual point release:

  • Update our three development systems and our three test systems

    • Three systems each to support Linux, Windows, and macOS

    • Separate development and test systems to determine missing dependencies. Most users don’t have a full development environment, so not all libraries may be available.

    • Finds other errors such as when paths are hard coded to a location on the dev machine

  • Update the main CMakeLists.txt to current version of Optizelle

  • Update README.md

    • Optizelle and dependency version numbers

    • Links to dependencies

    • Links for Optizelle, source, and documentation

  • Update license files for all dependencies and check that we’re still in compliance

  • Update license file and copyright for Optizelle

  • Update dependency versions and links in the LaTeX documentation

  • Determine new build quirks in the compilation, e.g. new flags to successfully build Windows or macOS packages

  • Check if build procedures for dependencies have changed

  • Check what dynamically linked libraries must be bundled from the C++ compiler to ensure that MATLAB/Octave run appropriately

  • Run all unit tests

    • Some tests will fail due to iteration changes

    • Check each failed test to determine if rebasing should occur or how much we care about this particular test

    • Test results differ between platforms due to variations in how floating point arithmetic is computed

  • Update AUTHORS.txt to reflect any merged pull requests

  • Build the documentation twice for letter and A4 versions. Add covers.

  • Update the information/product page on the company website

  • Add an announcement for the new release to the website

  • Add an announcement for the new release to the message board

  • Recheck that all links in the README.md, documentation, and website work

Candidly, the list goes on. In addition, there are other steps that should be checked, but we automate. This includes:

  • Updating any changes to the examples in the manual

  • Updating any output from the examples in the manual

Now, these points above are not unique to Optizelle. In fact, well run development teams for any product run through each of these steps and more. At the same time, this illustrates that new releases cost time and labor. In fact, larger development teams tend to include a DevOps position that maintains this infrastructure. They are a major resource to their team.

This brings us back to Optizelle and why releases are so far spread apart. Optizelle’s code base grew out of an immediate need for a second-order, matrix-free, unconstrained optimization code that scaled to hundreds of millions of variables. Over time, that need expanded to equality constraints, inequality constraints, and cone constraints. It also grew to include support for Python and MATLAB/Octave. That said, the original design of the code was not conducive to making the long term maintenance easy. Certainly, the code is maintainable, but it costs labor.

Overtime, our experience with Optizelle also led us to better understand what algorithms worked best and how to structure both the algorithm and the code to minimize its maintenance. To that end, we developed an expansive prototype code with a new set of algorithms and interfaces. This is the code that we currently use with our contracts. At the same time, we have an obligation to maintain our current set of open source tools. However, since the cost of this maintenance is high, the updates come infrequently.

Thankfully, there’s an easy fix for this problem. We need to transition the prototype code to the new open source code, which aligns our development and maintenance interests. This is happening. It has taken time since it requires us to context switch between paying client work, mathematical research, new development, and maintenance.

All that said, we appreciate everyone’s patience. If anyone would like more information, feel free to post a new topic on our user forum. If someone is interested in what our new solvers can do for a private contract, please don’t hesitate to contact us as well.