[Home]ReleaseCheckList

LinuxCNCKnowledgeBase | RecentChanges | PageIndex | Preferences | LinuxCNC.org

Search:

Difference (from prior major revision) (no other diffs)

Changed: 23c23
# Update debian/changelog. For emc2, make sure the version at the top is "1:$VERSION", so for example "1:2.4.8". For linuxcnc, make sure the version at the top is "$VERSION", so for example "2.5.0", *without* the leading "1:".
# Update debian/changelog. Make sure the version at the top is "1:$VERSION", so for example "1:2.4.8".

How to make a new release of LinuxCNC

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

This assumes the current release branch workflow - master has new developments, make a branch for each release series (v2.4, v2.5, etc).

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 all this work on the branch you want to release...

  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".
  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".
  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 a release manager key. Currently accepted keys are:
            pub   1024D/96935D7D 2004-05-29
                  Key fingerprint = D665 E21F B423 5D79 03C3  F6E9 25DD 3531 9693 5D7D
            uid                  Jeff Epler <jepler@unpythonic.net>
            sub   1536g/C6D94B20 2004-05-29
    
            pub   1024D/BC92B87F 2003-03-14
                  Key fingerprint = 813A 9DA3 C680 6FCC 4634  BE40 445B 1785 BC92 B87F
            uid                  Chris Radek <chris@timeguy.com>
            sub   1024g/5C04EC87 2003-03-14
  8. Push the commit and the tag together.
  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!

Other tasks

Update the wiki front page. And the Released wiki page.

Update the www.linuxcnc.org front page.

Update the #linuxcnc and #linuxcnc-devel topics.

Put debs into linuxcnc.org debian archive. (Chris Radek has access to this.)

  1. Source release on Sourceforge.net
    1. Upload the .tar.gz on frs.sourceforge.net/ (WebDav?, SCP or webinterface)
    2. Make a new Release, and link the previously updated .tar.gz

  1. Announcements
    1. News announcement on www.linuxcnc.org
    2. News announcement on sourceforge.net/projects/emc
    3. E-mail to emc-users & emc-devel
    4. Wiki updates

Some notes on tagging

To make the release tag: shell> git tag -u 495fa820 -s v2.5.0-pre2

To list tags: shell> git tag -l v2.5* v2.5.0-pre0 v2.5.0-pre1 v2.5.0-pre2

To verify a tag:

shell> git tag -v v2.5.0-pre2
object 1ef58691e0fd614c7348b94aee448b8c41d08b88
type commit
tag v2.5.0-pre2
tagger Sebastian Kuzminsky <seb@highlab.com> 1316561259 -0600

        debug fake release do not sue
        gpg: Signature made Tue 20 Sep 2011 05:27:46 PM MDT using RSA key ID 495FA820
        gpg: Good signature from "DEBUG EMC2 Release Manager <seb@highlab.com>"

To verify a tag you need the pubkey in your keyring: gpg --keyserver pgp.mit.edu --recv 5C04EC87

So... Make a list of tags matching the branch's glob, sort it newest first, walk down list verifying signatures until we find a good one, then use that tag to make the version:

<tt>shell> git describe --match v2.5* v2.5.0-pre2

shell> git describe --match v2.5.0-pre1 v2.5.0-pre1-660-g1ef5869


LinuxCNCKnowledgeBase | RecentChanges | PageIndex | Preferences | LinuxCNC.org
This page is read-only. Follow the BasicSteps to edit pages. | View other revisions
Last edited June 26, 2012 10:33 am by SebKuzminsky (diff)Published under a Creative Commons License