After a long period of testing we have finally released DMDirc 0.6, and we think this is the best version of DMDirc to date with over 250 feature additions, bug fixes and other changes, including:

• Themes system revamp to allow multiple themes to be loaded at a time
• Completely redesigned Actions Manager and Actions Editor dialog (see our previous coverage of these)
• New installer for OS X
• The Linux installer can now be used for BSD-like OSs that have Java pre-installed
• The Linux installer can now be used on Open Solaris
• The automatic updater can now update plugins

As of DMDirc 0.6 we now support running on more platforms than before: we have installers for Linux, BSD, Solaris, OS X and Windows, as well as a standalone Jar file for any other platforms that we don’t currently provide an installer for.

Users of DMDirc 0.5.6 (or the recent unstable releases) should be prompted by the updater (if enabled) to update to the latest version of DMDirc. Alternatively, you can visit our downloads page to grab the latest version yourself.

With DMDirc 0.6 (finally!) released we are looking forward to our next release, DMDirc 0.6.3. This will include support for SOCKS proxies, improved support for SSL Servers, a nicer looking Preferences dialog, server lists and more.

As always, we welcome bug reports and feature requests on our issue tracker, irc channel or as comments on this post.

As you can see from the screenshot we now show an info blurb, version and author for all action groups that provide them. In the future, we plan to allow users to edit action groups’ meta-data from inside the UI. This will make it a lot easier for end users to create action packs and make them available to a wider audience through our addons site, but for the moment only the name of the group is editable.

Settings for a particular group are now displayed underneath the group and are editable using the same components as the preferences dialog. Exposing these to the end user has added a lot more flexibility to actions and should enable them to be used in much nicer ways.

Finally, in the previous incarnation ‘wrapped’ actions groups (such as profiles and aliases) were visible but appeared empty. This was rather odd behaviour, so we remedied this and now show the contents of all groups. This allows users to edit the automatically created actions, so they can see how they work or use more advanced features that the wrapper UI doesn’t expose. The new UI is also a lot more pleasing to the eye.

Of course, the Actions Manager is only half of the actions UI; the Actions Editor has also undergone a revamp in 0.6. In DMDirc 0.5.5, we introduced Condition trees, but at the time they were only usable if you manually edited the action’s file in your profile, something which we don’t expect normal users to do. The new Actions Editor UI exposes condition trees and allows for easy selection of ‘AND’ and ‘OR’ trees, which should bring the added power of condition trees to more users.

As with the Actions Manager, we think the new Action Editor is much more user friendly than its previous version. You can, for instance, now see all the information about the action on one screen and edit them easily without having to switch between tabs. Of course, we’re always willing to improve further, so if you have any suggestions, please leave a comment!

From the start we wanted DMDirc to be an excellent client, and we quickly got it into a usable state (I have logs showing me using it in early May 2007). To help us do this we registered with Google Code, which provided us with a Subversion repository, download hosting and an issue tracker.

In addition to the tools on Google Code we also wrote a service that received error reports from DMDirc clients, and allowed developers to browse them using a web interface. This system never really worked too well; it meant that we in effect had two systems for tracking errors, the automated error system (which was checked manually, and therefore quite infrequently) and the user-facing Google Code issue tracker. The Google Code issue tracker also had quite a few issues of its own [ba-dum-tish] that posed problems for us: we didn’t have much control over it, Google were slow to improve it, and it didn’t allow for dependencies or private issues. The lack of private issues was the reason we felt the need to have two separate systems at the time — automatically reported errors may in some cases contain private information, so we can’t show them publicly.

Sometime just before DMDirc 0.5.5 was released, we decided to start using Mantis as our primary issue tracker. Mantis, whilst not perfect, gave us the control we wanted — it’s written in PHP (which, like Java, we all know very well), and is easy enough to modify. We imported all of our existing issues from Google Code, using a Python script (yay for multi-language proficiency!) to screenscrape the website and build an XML file, and then a PHP script to read the XML file and import the issues into Mantis. With the issues imported, we set about modifying Mantis to better suit our needs.

We (well, Chris and I) had got quite used to using the issue ‘grid view’ offered by Google code, so one of the first things we did when switching to Mantis was implementing our own version of it. We also improved the error reporting backend to raise new Mantis issues (marked as private, of course). Later on, we also enabled SVN integration, which initially meant writing a script to parse e-mails from Google Code (where our SVN repository was still hosted) and passing the information on to Mantis for it to use. After a while, we modified the integration to include links to our Fisheye instance, and also map Subversion users to Mantis users in order to add comments with the appropriate username instead of just ‘SVN user’.

More recently, we’ve improved the Fisheye aspect of the integration dramatically; we now access Fisheye and include its representation of the changes directly in Mantis, allowing you to see a list of affected files and even view diffs of the changes without leaving the issue page. We also parse any stack traces in the issue description, and automatically link relevant lines to the Fisheye view of the specified file and revision, if the information is available. You can see an example of both of these modifications in this issue.

Now, as I mentioned above, we are all heavy IRC users so having to periodically check Mantis for new bugs wasn’t very appealing to us, so we modified it some more so that it communicated with an IRC bot we have which is designed to relay notifications. Mantis tells us everything that happens — new issues, edited issues, property changes on issues — anything that happens there, we instantly know about it.

This setup worked well for us for about 4 months, after which we decided to switch over to using a self-hosted SVN Repository, which opened up even more possibilities. We added post-commit hooks to replace the email-parsing hacks for Mantis support, enabled reporting of commits to IRC, and created a pre-commit hook to make sure that every commit was linked to an issue on Mantis.

Not long after that we discovered and implemented Bamboo into our development process. Bamboo is a Continuous Integration server, which means that every time we commit something to the trunk (or active branches), it will rebuild the project on our server, run our collection of unit tests and then publish and store the results. Bamboo also notifies us via Jabber if you cause a build to fail. Of course this wasn’t quite perfect, and after a short while we discovered a plugin that can execute post-build scripts. One Bash script later and Bamboo was reporting to IRC like everything else. We also, of course, integrated Bamboo with Mantis. If you check this issue again you will see that the results of the build from Bamboo are also reported under the the commit that triggered it.

As mentioned before, we have a collection of unit tests to make sure things work as expected. Every so often we generate Clover reports to show how much code coverage we have, and in the last month we have also discovered and began using the FEST Swing library to allow us to start unit testing the DMDirc GUI.

So as you can see, what we have now is a very tightly integrated system to help ensure that DMDirc is a quality product. Everything reports to IRC so we know as soon as things happen, our issue tracker is almost omnipotent in that it can tell nearly everything about an issue from being raised to being fixed, and to top it all off, we have Nagios running and monitoring it all for us (and of course, this reports to IRC also!)

Of course this setup wouldn’t be possible if it wasn’t for a few choice products provided for free — Mantis, Fisheye, Bamboo, Clover and many others. We would like to thank the developers of these products for helping us make DMDirc great.

Why “the intelligent IRC client”? Well, we think DMDirc’s built-in ‘intelligence’ is the most significant aspect that sets it apart from other clients. We’ve yet to see another IRC client that has tab-completion anywhere near the quality of DMDirc’s, or that parses links as well as we do. We have more enhancements coming for both of these areas, too, as well as plans to make other DMDirc features more ‘intelligent’.

While the two areas mentioned above may not seem ground-shatteringly important, they improve the usability of the client quite a lot. The difference they make is most noticeable when you use another IRC client, and find that you can no longer tab-complete command names, or that a link in the topic includes a closing quotation mark when you click on it, which means you have to do something extra (open the manual to look up the command name, manually copy the URL or modify it in the browser, etc) in order to do/find out what you want, instead of it just working.

DMDirc 0.6 (coming soon; we’re going to be pushing out an alpha version this weekend) features a lot of enhancements to the ‘intelligent’ aspects of DMDirc, some of which we’ve discussed previously. But, as always, we’d love to hear from you if you have any suggestions on how we could make DMDirc more intelligent. Feel free to leave a comment on this post, create a new issue on the issue tracker, join us in #DMDirc on Quakenet, or use the feedback form found in the Help menu in the client itself.

Looking back on the 0.6 branch, one of the things we’d like to change most is the length of time between each release. Ignoring security and bug fixes, there was a four month gap between 0.5 and 0.5.5, and it looks like DMDirc 0.6 will be released between six and seven months after that. This isn’t because we’re getting lazy, or because we care less about DMDirc than we did when we released the first few versions (which were all inside of the same month); it’s because we’re implementing more features, fixing more bugs, and doing more behind-the-scenes work (improving the DMDirc code base) than we have in previous releases. To combat this somewhat, we’re aiming to make three releases as part of the 0.7 development series - DMDirc 0.6.3, 0.6.6 and 0.7. We’ve allocated issues to each release to try and balance the time it will take (DMDirc 0.5.5 wasn’t a pre-planned release and, as you can tell from the timing, didn’t split the workload too well), so hopefully we’ll be able to make releases somewhat more frequently than we have been.

Pre-planning these sub-releases has also enabled us to organise issues better so that we’re working on (and releasing) related features at the same time. The rough focus of each release is described below. Note that these are just the major, overarching themes; each release also contains a good helping of smaller, independent enhancements.

• DMDirc 0.6.3: Server lists, input/command improvements, plugin improvements
• DMDirc 0.6.6: Updater overall, installer and launcher improvements
• DMDirc 0.7: Channel and general window/UI improvements

Of course, if you can’t wait for releases to try out all the new features, you can download a nightly build, which can auto-update with the latest features and bug fixes each day.

As you probably know, DMDirc is written in Java which gives us a huge advantage as far as cross-platform compatibility is concerned. Java runs on all the major operating systems so most of the hard work has been done for us.

Up to DMDirc 0.5.6 we only supported Windows and Linux and provided a separate jar-only download for other platforms. For 0.6 the supported list of operating systems has more than doubled; we now package DMDirc for:

1. Linux
2. Windows
3. OS X
4. Open Solaris (and normal Solaris)
5. BSD (tested on PC-BSD, which is FreeBSD at the core)

This pretty much covers all major non-server operating systems, which we are quite pleased about.

The Installer for DMDirc runs on all of the above systems (apart from OS X, which has its own installation method) and where possible can download and install Java automatically. Currently the only exception to this is BSD, where users will need to compile the jdk16 port manually — unfortunately Sun’s licensing prevents redistribution of the modified JRE used on BSD.

The nightly builds have been working on all of the above operating systems for a while now, and you can browse and download the installers from our nightly builds page.

To do this we needed to be able to create a DMG file to distribute it in, and we wanted this to be done by our current build scripts. As you may be aware, we do all of our development on Ubuntu Linux (which we also use on the DMDirc build/web server) so our current build scripts are a bunch of bash scripts that build the various installers (.run files for Linux, and .exes for Windows).

Other projects exist which distribute their cross-platform releases on Linux, OS X and Windows, so I looked at the build processes for both Firefox and Inkscape which both have apple releases. Unfortunately both of these projects appear to use an Apple machine to create the releases. This roughly translated to the following:

	# DMDirc-dmg contains the files we want to put in the dmg
	hdiutil create -volname "DMDirc" -fs HFS+ -srcfolder DMDirc-dmg -format UDRW DMDirc.RW.dmg
	hdiutil attach DMDirc.RW.dmg
	bless -openfolder /Volumes/DMDirc
	hdiutil detach /Volumes/DMDirc
	hdiutil convert DMDirc.RW.dmg -format UDZO -imagekey zlib-level=9 -o DMDirc.dmg

Which, while it does work (and is what we use if the installer is being built on OS X), wasn’t an acceptable solution as it relied on an OS X install.

I then discovered a wiki page which describes a method that works under Linux. After compiling a Linux-compatible version of Apple’s mkhfs program we could now do something along the lines of:

	# DMDirc-dmg contains the files we want to put in the dmg
	SIZE=$((`du -sb DMDirc-dmg | awk '{print $1}'`  + 10))
	if [ ${SIZE} -lt 4194304 ]; then
		echo "Size is less than 4MB"
		SIZE=4194304;
	fi;
	dd if=/dev/zero of=DMDirc.img bs=${SIZE} count=1
	mkfs.hfsplus -v 'DMDirc' DMDirc.img

	mkdir DMDirc.img-mounted
	mount DMDirc.img-mounted
	MOUNTRES=${?}
	if [ ${MOUNTRES} -ne 0 ]; then
		# Try using full parameters - could be running as root.
		mount -t hfsplus -o loop DMDirc.img DMDirc.img-mounted
		MOUNTRES=${?}
	fi;
	if [ ${MOUNTRES} -ne 0 ]; then
		echo "Unable to mount, need root access or an fstab entry like:"
		echo "${PWD}/DMDirc.img ${PWD}/DMDirc.img-mounted auto users,noauto,loop 0 0"
		exit 1;
	fi;
	mv -fv $DMDirc-dmg/* DMDirc.img-mounted
	mv -fv DMDirc-dmg/.[A-Za-z]* DMDirc.img-mounted
	umount DMDirc.img-mounted
	mv DMDirc.img DMDirc.dmg

This was an improvement, as images could now be created under Linux, however it still also had lots of problems:

• images have to be at least 4MB (compared to 1.3mb when created using the OS X method),
• they’re created read-write (compared to read-only when created using the OS X method), and
• they do not auto-open when mounted (the OS X method can “bless” the image).

After a short while, I discovered the gentoo wiki had a page on hfsplus, which had a version of diskdev-cmds that allowed for images that were as small as 512kb. Using this, I was able to edit the first part of above code to something like:

	# DMDirc-dmg contains the files we want to put in the dmg
	SIZE=$((`du -sb DMDirc-dmg | awk '{print $1}'`  + 10))
	if [ ${SIZE} -lt 524288 ]; then
		echo "Size is less than 512kb"
		SIZE=524288;
	fi;
	dd if=/dev/zero of=DMDirc.img bs=${SIZE} count=1
	mkfs.hfsplus -v 'DMDirc' DMDirc.img
	# however older versions of mkfs.hfs will only create 4mb+ sized images :/
	if [ $? -eq 1 ]; then
		if [ ${SIZE} -lt 4194304 ]; then
			echo "Size is less than 4MB"
			SIZE=4194304;
		fi;
		dd if=/dev/zero of=DMDirc.img bs=${SIZE} count=1
		mkfs.hfsplus -v 'DMDirc' DMDirc.img
	fi;

This still produced 3.8mb images, so basically had all the same problems as the old method. The actual code we used was also a lot less tidy as sometimes the size returned by du was too small, so the code looped increasing the size until it got a successful image.

However I recently discovered a much tidier method, which we now use. mkisofs has the ability to create and bless hfs images:

	# DMDirc-dmg contains the files we want to put in the dmg
	mkisofs -V 'DMDirc' -no-pad -r -apple -o "DMDirc-dmg" -hfs-bless "/Volumes/DMDirc" DMDirc.dmg

This code has the advantages of:

• being much tidier than the old code,
• not requiring a loop to get a correctly-sized image,
• being able to bless the image,
• creating a read-only image, and
• not requiring a patched version of Apple’s diskdev-cmds

All that was left now was to fix the file size (which was still 3.8 mb). To do this, I found a new project (libdmg-hfsplus) which is a DMG manipulation library for Linux capable of producing compressed DMG files. I jumped at this, downloaded and compiled it, and came up with:

	# DMDirc-dmg contains the files we want to put in the dmg
	mkisofs -V 'DMDirc' -no-pad -r -apple -o "DMDirc-dmg" -hfs-bless "/Volumes/DMDirc" DMDirc.dmg.pre
	./dmg dmg DMDirc.dmg.pre DMDirc.dmg

I copied this image to an OS X machine and tried to open it and was greeted by a “CRC Mismatch” error. After digging around a little I found the cause of this (The code generates a “Master Checksum” which always seems to generate the same for converting DMGs using the code above, but OS X doesn’t like it), and produced a patched version of libdmg, which can be found on my personal website: http://shanemcc.co.uk/libdmg/, along with a script that will patch it for you if you want to compile your own.

With this newly patched version of the DMG binary from libdmg-hfsplus we are now able to produce DMDirc.dmg on both OS X and Linux with similar results (read-only, blessed and compressed).

It is also worth pointing out that Java 6 for OS X is no longer a “developer preview” only, and can be obtained by anyone with a 64-bit Intel-based Mac running 10.5.2 or later from the Apple website. I would imagine that it is also available using the software update facility in the Apple menu.

OS X nightly builds of DMDirc are available on the nightly builds page of the website.

We have backported the fix for the exploit to the DMDirc 0.5 tree, and DMDirc 0.5.6 has now been released. We highly recommend that anyone using DMDirc 0.5.5 upgrade to DMDirc 0.5.6. Nightly builds of DMDirc up to and including the build released on the 22nd of May (designated revision 4055) are also vulnerable. A nightly build containing the vulnerability fix will be available for download tonight, and we highly recommend that anyone using DMDirc nightly builds upgrade as soon as it is available.

DMDirc 0.5.6 may be downloaded directly using the following links: Windows installer, Linux installer, Jar file.

If you have any questions, please feel free to join us in #DMDirc on Quakenet (irc.quakenet.org), or leave a comment here.

We have also relocated our subversion repository from its previous home at Google’s Project Hosting service, to our own server. We made this switch because of the fairly poor uptime of Google’s offering, and the seemingly random delays between commits being made and announcement e-mails being sent. If you have the DMDirc source code checked out from our subversion repository, follow the instructions here to migrate to the new repository.

If your machine fits the bill, you can download the developer preview from the Apple Developer site:

• Go to http://www.apple.com/java
• Click on “Java Downloads”
• Click on “Java SE 6 Developer Preview” — This will redirect you to the ADC site.
• Login to the ADC site (you may need to register first.)
• Click on “Downloads”
• Click on “Java” in the sidebar
• Download the “Java SE 6 Developer Preview”
• Install

Once you have the developer preview installed, you can download a nightly build of DMDirc from http://www.dmdirc.com/nightlies or you can build your own by checking out the source code from our subversion repository (if you have the developer tools installed) by running the following commands:

svn checkout http://dmdirc.googlecode.com/svn/trunk/ dmdirc
cd dmdirc/trunk/installer
./release.sh --target osx this
mv output/DMDirc.dmg ~/Desktop/DMDirc.dmg


Now you can mount the image, and drag DMDirc to the applications folder to install it.

However, at the moment there is a bug with the “First Run Wizard” that we use to extract plugins and actions for the first time, so you will need to run the following in a terminal prior to running the client to make it work. This assumes that you installed DMDirc into the Applications folder and not somewhere else.
Edit: This bug has been fixed.

mkdir -p ~/Library/Preferences/DMDirc/
cd ~/Library/Preferences/DMDirc/
unzip /Applications/DMDirc.app/Contents/Resources/Java/DMDirc.jar plugins/*.jar com/dmdirc/actions/defaults/*
mv com/dmdirc/actions/defaults actions
rm -Rf com
echo "general.firstRun=false" >> dmdirc.config
echo "general.addonrevision=10" >> dmdirc.config
echo "updater.enable=true" >> dmdirc.config
echo "general.submitErrors=true" >> dmdirc.config


The last two lines can be omitted if you do not wish to receive update notifications, or automatically send error reports to the developers. We would however prefer you to have them both enabled.

Now you can enjoy DMDirc on OS X :)

Feel free to raise any issues on our bug tracker, leave a comment here, or contact us in #DMDirc on Quakenet

In DMDirc 0.6, we’ve taken this one step further. Commands can now specify exactly what group(s) of targets should be used - so, for example, the first argument of the /ctcp command will now only tab complete to nicknames and channel names (but not command names, as it would have done in DMDirc 0.5).

We’ve also added support for what I call “deferred intelligent tab completion”. This comes in to play with the half-dozen or so commands that take another command as one of their arguments, such as the /alias command, which takes an alias name and then a command to associate with that alias. So, say you want to create an alias to start a timer that will CTCP PING a certain person after five seconds. You type: /ali<tab> ping /tim<tab> 1 5 /ctcp Nickname <tab>. When you hit that final tab, DMDirc suggests eight standard CTCP types (PING, FINGER, VERSION, etc…), even though the CTCP command is in the middle of a much larger command. How’s that for intelligent tab completion?

As far as I’m aware, no other IRC client comes close to the intelligence of DMDirc 0.5’s tab completer, so DMDirc 0.6’s puts us leagues ahead of the competition in that respect. But, as ever, we’re eager to hear any feedback or suggestions that you might have - feel free to leave a comment here, drop by #DMDirc on Quakenet to talk to us, or use the “Send feedback” feature (available in the help menu) of DMDirc 0.5.5.

Some of the main changes include:

• The new launchers which give the client the ability to update itself via the updater
• URL Handler to allow adding support for non-http links (Eg steam://, ftp://)
• Much improved plugin system (Plugins are now stored in jar files rather than loads of .class files)
• Many more, read the changelog for a full list.

The installer for DMDirc 0.5.5 can be downloaded for Windows or Linux.

We took this opportunity to move plugin configuration settings into the main preferences dialog. This makes the configuration options for individual plugins much easier to find, and reduces the amount of clutter in the Settings menu somewhat. Here’s a screenshot of the new prefs dialog — you can see the configuration categories for all of the plugins I have installed, as well as the plugin manager itself in its newly integrated state:

We still have some more improvements planned for the preferences dialog in 0.6, including a new component to allow easier editing of duration fields (no more entering times in milliseconds!), and better management of optional colour fields.

In other news, DMDirc 0.5.5’s release is drawing very close. DMDirc 0.5.5 has been the most tested release to date, and we’re working out the last few problems now. You can view the current changelog or the draft release notes if you’re interested in the changes since DMDirc 0.5.1. If you want to try it for yourself, or want to help us test it, you can try an unstable release of DMDirc.

Firstly, the Linux installer was overhauled to show all of its messages in GUI dialog boxes where possible (using kdialog under KDE or zenity under gnome). This means that users don’t need to be running the installer from a console to see what went wrong. (The messages are still also relayed to the console). This update is part of the DMDirc 0.5.5 release, which should be available soon.

The next major change is that both the Windows and Linux installers are now capable of installing Java, either by using a JRE bundled with the installer or by downloading one from java.com. This is a major positive step as it means that it is possible for people who don’t have Java (or have an outdated version) to use DMDirc.

This new functionality is in all the nightly installers from December 24th onwards, comments/bug reports etc are welcome here and on the issue tracker.

An example condition tree looks like this: (0&(1|2)&!(1&2)). The numbers refer to the outcome of the conditions (in this case my action has three conditions, which get numbered 0, 1 and 2), and &, |, ! and the brackets have their expected meanings. If you’re not too fluent in boolean logic, the condition tree translates roughly as “condition 0 is true, and exactly one of conditions 1 and 2 are true”, or “condition 0 and (condition 1 XOR condition 2)” if you want.

At a basic level, condition trees allow you to reduce the number of actions you have (for example: if you want to do something whenever someone mentions your nickname OR when someone starts a message with “!hello”, in DMDirc 0.5.1 and below you need two actions with duplicate trigger/response/format settings; in DMDirc 0.6 you will only need one action with a condition tree set). Beyond that, condition trees allow a much closer approximation to ‘if’ statements in scripting languages, thus enabling extremely complex conditionals without the overhead of a scripting language or the learning curve of one.

To pre-emptively answer a few questions:

• Condition Trees are called Trees because of their implementation, rather than their function. Each ConditionTree object has exactly one operation (and, or, not, noop [used for empty brackets and trees] or var [used to look up the result of a condition]), and zero (in the case of noop or var), one (in the case of not) or two (in the case of and and or) child condition trees.
• The title of this blog post is a reference to a question another developer asked when I was talking about condition trees - it went something like “are you *trying* to make the actions system more incomprehensible?!”; my reply: “no, I’m trying to make it more powerful; incomprehensibility is just a side-effect”.
• We will be having a UI for condition trees in 0.6, but we’re not entirely sure of the details yet. Stay tuned for details later in the development cycle.

As a newcomer to the DMDirc project, I’d thought I’d introduce myself. I’m Chris ‘laser’ Northwood, and just before the releases of the 0.5 release candidates, I was asked by the other developers on DMDirc to become the QA Lead.

My approach will hopefully become fully implemented for the 0.6 release, and we’ll hopefully see this by having fewer bugfix releases (particularly, less release candidates), as I did not have enough time to implement this for the 0.5 release.

My experience in testing is mainly in functional testing (I’m currently working as a Test Engineer for Sophos, a computer security company), so I’m going to be mainly concerning myself with functional testing, leaving the current unit testing approach to be worked on by the other developers.

The biggest problem I’ve found since joining the DMDirc team is a lack of documentation, which is essential to ensure a good set of test coverage. Greboid has so far developed a pretty good functional specification for the UI, which I can work from, however there are a few other changes I’m hoping to make to ensure the focus on QA. First off is a “Requirements Dashboard”, matching new, changed and existing functionality to a specific requirement, allowing us to check dev status and test case coverage for a specific requirement (see, this mockup dashboard).

Each requirement should have a test case to verify the functionality before testing can begin to ensure a good testing strategy to increase quality of the DMDirc releases.

We currently use a handful of different tools (specifically, Google Code Issue Tracker and Litmus) for QA, which although are good on their own, do not necessarily integrate together well, which is where my dashboard idea is hoping to pull them all together.

I’m also hoping to change the release strategy of DMDirc. Currently, testing is continuous on feature incomplete nightly builds, and release candidates are generated as soon as DMDirc is feature complete. Some of my changes are mainly semantic, but should hopefully clarify the process.

• Nightly builds are still generated, but these are mainly for quick testing and developers rather than the more extensive general testing.
• Once all features for that milestone are implemented (i.e., the dev status on the dashboard is all green), and all defects raised against the last release of DMDirc fixed, a Feature Complete build is released with which the DMDirc QA team can run test cases. Additionally, any defects raised against the last release of DMDirc are verified at this point.
• Any raised bugs are then fixed by the dev team until all test cases have been executed, and raised defects fixed, when the developers release second build to the DMDirc testers, who verify the defects raised against the previous build.
• When the testers are satisfied that there are no unverified raised defects, and nothing caught in testing, a release candidate is published, which will allow DMDirc to be tested in user environments.
• If any issues are raised by the release candidate, a new one is released until these are resolved.
• When a release candidate has been released and no issues identified with it, the release candiate becomes a released final build, and developers can move on to developing new features for the next milestone.

I’ve created a workflow to hopefully show how I intend this to work:

This is not too dissimilar to the current process, just slightly formalised.

Hopefully I’ll be able to implement this with no real trouble, which means that come 0.6, you’ll be able to see the benefits in a more bugfree release.

Chris Northwood,
QA Lead

The installer for DMDirc 0.5.1 can be downloaded for Windows or Linux.

0.5 has just under 100 features or improvements and 77 bug fixes since 0.4, the major additions in 0.5 are

* Added action wrappers for aliases and performs
* Added intelligent tab completion for commands
* Added server settings dialog
* Added support for themes
* Added support for character transcoding
* Added support for various command-line options
* Added installers for Windows and Linux

See the changelog for more information on this release. As always we recommend existing users to upgrade, and non-users to give it a go, come visit us in #DMDirc on Quakenet (see the help menu) with your feedback or just to visit.

0.5 can be downloaded for windows and linux

Substitutions
In 0.4 actions substitutions were somewhat of a black art, whilst they were quite powerful, they were nearly impossible to figure out, so we have added a UI component to both the actions response panel and condition editor making them much more accessible. When editing either of these you will be able to access a full list of available substitutions, which can be added at the current cursor position either by double clicking or using the button, or added any any position you like by dragging and dropping them.

Aliases

Perform

New for this release we have decided to build Release Candidate builds approximately every day.
Release Candidate builds are just like the final release: they are installed using the new installer, and they are feature complete for 0.5. Their purpose is help discover/iron out any last bugs before we tag and release 0.5 into the wild and begin on 0.6.

RC1 was released yesterday (Downloads: Linux and Windows) with RC2 hopefully being ready tonight.

Once we get an RC build with no apparent bugs, we will release 0.5 :)