Lumiera
The new emerging NLE for GNU/Linux

We have nothing to show yet and don’t provide public releases — but we ought to rehearse and practice the release process. This document contains some hints and a checklist of steps to perform for a proper release.

Important Lumiera uses Git-flow for the organisation of release branches and tags. Releases are still considered “experimental” and happen infrequently, so that a full automation of these steps was not yet considered. So please be sure to adhere to the established conventions.
Each Release has three phases

  • Development

  • Convergence

  • Preparation

During the »convergence phase«, all participants must prioritise code stability. After the »release cut«, development can resume freely on branch integration, while »release preparation« ensues on the release branch. The published documentation branch and the website will follow suit on the release branch. Please mark the current phase on the Development Status page.

Steps to perform for a release

  1. Pre-Release »convergence phase«

    • care for code stability and refrain from breaking changes

    • announce and mark »convergence« on the Status page.

    • verify that the current version number is already set to the version number expected for the upcoming release, yet decorated with the ~dev suffix — if it turns out that the upcoming release shall make a major version bump, then the expected version must be set now. Once the release branch has been forked, the version must not be changed any more.

  2. Release cut

    • create the Release Branch with name rel/#.#.#

    • after that fork, immediately perform the version bump on branch integration

      • use the Script: admin/buildVersion --bump=maj|min|rev --suffix=dev

      • typical usage 

      admin/setVersion `admin/buildVersion.py --bump -s dev`
      Important what you set here must be the next version after the release

  3. Release preparation: clean-up obsolete information

    • Debian package descriptions

    • Build-Tutorial

      • building from source

      • building the debian way

      • contributing

    • technical/build/Dependencies

    • check and update Release-Notes

      • check that README is up-to-date

      • add a new summary entry into NEWS

      • check the AUTHORS info

        • ensure that the copyright time span mentioned for each relevant contributor is correct and possibly spans the current year

        • it is crucial (legally relevant) that at least the person preparing the release and thus acting as publisher is mentioned here with the current year

        • ensure that a correct summary is presented in the "About" dialog of the GTK-UI. The necessary config is currently (2025) maintained in the file setup.ini (the info displayed here should be the list of all significant contributors and cover the whole time span from 2007 until NOW)

      • check that the LICENSE file mentions the core authors, again with the correct copyright time span

  4. Test phase

    • even while we have automated tests, be sure at least to do some “smoke test”. Ideally have someone else use the new version on a real-world project.

    • depending on the circumstances, possibly set a release candidate version,
      using a --suffix=rc.#

  5. Publish the Release

    • merge the release branch into master

    • set the version again, this time without any --suffix

    • amend the merge commit to include that final version

    • set the Release Tag in accordance with the Version-Number scheme.

    • fast forward also the release branch to sit at that tag

    • publish by pushing into git://git/lumiera/org/LUMIERA

      • the latest state of master

      • the release tag

  6. Back-Merge:
    never loose any release work

    • git checkout integration

    • git merge rel/#.#.#

    • work through possible merge conflicts and resolve them

    • conflicts on the version number must be resolved in favour of the next version number — you can perform that as an extra step, after the merge is otherwise complete: admin/buildVersion --bump ... --suffix=dev (and then amend the merge!)

    • delete the release-branch

    • push this delete to the public repos, incl the main repo!

  7. Packaging…

    • merge release-tag → branch deb

    • verify the package description

    • have a look at manpages and similar packaging documents;
      notably look into debian/README.Debian, since we deliver that instead of README for the Debian users, since they do not need instructions how to build the software…

    • update debian/control to reflect current version dependencies

    • have a look into debian/rules (e.g. build flags and similar)

    • update debian/copyright to reflect authors and copyright!

  8. Delivery

    • use whatever infrastructure is available to build packages.

    • verify packages can be installed on a pristine VM / Container

    • upload packages to debian depot or commit them to PPAs

    • clean-up and discard obsoleted old distributions and packages

  9. Close the Release Ticket and update the Status page.