DragonFly BSD


The art of releasing

This is a template on how to do a release.


On crater branch the repo:

cd /repository/git/dragonfly.git
git branch DragonFly_RELEASE_x_y        (e.g. 2_8)

This is the only step that needs to happen remotely.

On your own system:

Check out two copies of /usr/src, one with master checked out, one with the new release branch checked out. Checkouts should be under your user id, NOT as root, or the later tagging operation will be unhappy.

mkdir master
cd master
git init
git remote add origin ssh://crater.dragonflybsd.org/repository/git/dragonfly.git
git fetch origin

cd ..
cp -R master x_y 
# x_y is the release; faster than rechecking out
cd master
git checkout master
cd ../x_y/
git branch DragonFly_RELEASE_x_y origin/DragonFly_RELEASE_x_y
git checkout DragonFly_RELEASE_x_y 

On the new branch:

vi sys/sys/param.h      

Edit __DragonFly_version and related comments. You only need to add a commented version number for the branch, not the new master.

vi sys/conf/newvers.sh  

Edit BRANCH, use 'RELEASE', update version. e.g. RELEASE_2_8

vi gnu/usr.bin/groff/tmac/mdoc.local

In the "Default .Os value" section, bump up the version to that of the release (even minor number).

vi etc/Makefile.usr

Adjust the default src checkout in /usr/src/etc/Makefile.usr to pull this branch. Otherwise, anyone using the Makefile to download source will get master, and nrelease will build master.

On master:

vi sys/sys/param.h

Edit __DragonFly_version and related comments. Put in commented numbers for the new release and master.

vi sys/conf/newvers.sh  

Edit BRANCH, use 'DEVELOPMENT', update version.

vi gnu/usr.bin/groff/tmac/mdoc.local

In the "Default .Os value" section, bump up the version to that of the master (odd minor number). Additionally, in the "DragonFly releases not found in doc-common" section, add a new line (a la the previous ones) for the new master.

on master:

git push

on release:

git push


Make sure all changes on the master branch and on the new branch have been committed and pushed before tagging anything.

On release:

git add sys/sys/param.h sys/conf/newvers.sh gnu/usr.bin/groff/tmac/mdoc.local etc/Makefile.usr
git commit
git push

On master:

git add sys/sys/param.h sys/conf/newvers.sh gnu/usr.bin/groff/tmac/mdoc.local 
git commit
git push

man git-tag for info, the committer needs GPG set up so git tag -s works. Then you can use your own checkout. Be sure the checkouts are under your user id and you do the tagging as yourself instead of as root.

You may need to set GPG_TTY to get GPG to work if it tries to run pinentry-curses. This is the line for bash, since that's quoted most often for this fix.

export GPG_TTY=$(tty)

In master

git tag -s -m "DragonFly x.x.0" vx.x.0
git push --tags

In the new branch

git tag -s -m "DragonFly x.y.0rc" vx.y.0rc
git push --tags

Do the x.x.0rc immediately. Just before doing the final nrelease build roll a x.x.0 tag for the release branch - the same method, just without "rc" for release candidate. Release as x.x.0.

A new tag may require a commit beforehand to the release branch to make sure it goes to the right branch.

Subsequent tag updates

When updating a x.x.1 version, you just need to tag.

If there's a significant change between versions - major library change or third-party software update, which is more likely in the development branch of DragonFly - update param.h

vi sys/sys/param.h 

updating UPDATING

Generally, any files not specifically mentioned above as specific to a branch should be updated in master and then cherry-picked to the release branch. src/UPDATING is the most common example.

Something in GCC

The file gnu/usr.bin/cc41/cc_prep/config/dragonfly.h has a spot where the major version number for DragonFly is encoded. I don't know if this applies for anything other than gcc 4.1.

#define        DFBSD_MAJOR     3

This comes from John Marino's commit:



Adjust the default pkg checkout in /usr/src/etc/Makefile.usr for both master and the new branch if necessary.

Build isos and imgs

Set DPORTS_PATH when building the image to pick where dports comes from. Ideally, there should be a release tag in dports that corresponds with the DragonFly release.

git fetch --tags
git checkout TAGNAME

If your ISO is too big for a normal CD, try using:


To build it. (add pkg/gui/whatever targets as necessary.)


Testing should be done on real hardware, qemu and vmware. We have six isos/imgs that needs testing.

i386 iso, img, gui-img
x86_64 iso, img, gui-img

Test this:

Release Notes

Copy one of the existing release pages. The general format is :

Minor releases

File Copy

Place images in /ftp/iso-images on crater.dragonflybsd.org. They will be rsynced to mirror-master.

The file md5.txt should have the md5 output for all the compressed files. It should also have the md5 output for the uncompressed images, so don't just 'md5 *bz2 > md5.txt'; get that separately and copy it into the document.

/root/adm/domd5.sh will get the MD5 sums for the compressed and uncompressed images and print them to stdout.


users@, web page, Hacker News, Slashdot, Reddit