LinuxCNCKnowledgeBase | RecentChanges | PageIndex | Preferences | LinuxCNC.org


If you're not a release manager, you don't have to care about any of this.

Our release branch workflow is:

Creating a new stable branch

We aim for a new stable branch every 6-12 months.

How to make a new stable branch:

Making a new Live/Install Image

The Live/Install Image is made from the git repo here: http://timeguy.com/gitweb?p=live-images.git;a=shortlog;h=refs/heads/debian

Copy the new Live/Install Image to www.linuxcnc.org.

If this is the first Live/Install Image for this version of LinuxCNC, add it to the Download page here: http://www.linuxcnc.org/index.php/download

If this is an update to an existing Live/Install Image, update the checksums recorded in the Getting Started guide and on the website here: http://www.linuxcnc.org/index.php/download

Making Releases

Prep work: write and translate the Updating instructions

A week or two before the release, update the appropriate wiki "updating" pages (http://wiki.linuxcnc.org/cgi-bin/wiki.pl?UpdatingTo2.5 and http://wiki.linuxcnc.org/cgi-bin/wiki.pl?UPDATING), and the User Guide document.

This document needs to explain any changes a user needs to do in order to upgrade to the new release version. Typically this is only needed for new major versions.

Notify the translators and let them translate the update instructions.

To release

Do this work on the branch you want to release, for example "2.6".

  1. Find the version you want to release.
  2. Ideally make it so no one will commit to the release branch while you're working, but I'm not sure how to do this.
  3. Pick a version number. This must be a valid debian version number. For example: "2.4.7" "2.5.0~pre2". In the second example, notice that it is a tilde character, not a dash! In debian version numbers, X~Y sorts as less than X, so it works well in the "pre" role we use it for. Let's call this string "VERSION".
  4. Update debian/changelog. Make sure the version at the top is "1:$VERSION", so for example "1:2.4.8" or "1:2.7.0~pre1". An easy way to do this is to run dch -v $VERSION. In the editor, add a changelog based on the list of commits since the previous release. (Use something like this: git log --oneline $PREVIOUS..)
  5. Update the VERSION file to the $VERSION number you picked above, not including the "1:". So for example, "2.4.7" or "2.5.0~pre2".
  6. Commit but *don't* push.
  7. Make a signed, annotated tag named "v$(VERSION)", but with any tilde character "~" replaced with a dash "-", pointing at the commit you just made. For example "v2.4.7" or "v2.5.0-pre2". It should be signed with the Release Manager's key. So for example: git tag -u 'LinuxCNC Release Manager' -s v2.6.0-pre1 -m 'LinuxCNC v2.6.0-pre1'
  8. Push both the branch and the new tag together, for example: git push origin 2.6 v2.6.0-pre1
  9. The buildbot will build and test, and put the packages in the release repo: http://buildbot.linuxcnc.org/release/

Writing Release Notes

Say if users need to make any config changes.

Include highlights from changelog.

Give credit to developers, documenters, & testers! You can list the people who wrote commits between two releases like this: git log --format='%aN' v2.6.12..v2.6.13 | sort | uniq

Other tasks

Put the new debs into the http://www.linuxcnc.org debian archive.

Create a new Post for the http://www.linuxcnc.org front page. Update the _data/releases.yml to point to the new release.

Update the #linuxcnc and #linuxcnc-devel topics.

Update the Released wiki page.


  1. News announcement on the www.linuxcnc.org front page
  2. E-mail to emc-users & emc-devel
  3. Wiki updates

If it's a major release (ie going from 2.5.x to 2.6.0), update the links on the Documentation part of the main www.linuxcnc.org webpage.

LinuxCNCKnowledgeBase | RecentChanges | PageIndex | Preferences | LinuxCNC.org
This page is read-only. Follow the BasicSteps to edit pages. | View other revisions
Last edited November 4, 2016 6:59 am by SebKuzminsky (diff)
Published under a Creative Commons License