I've been a bit lax with making regular updates to this blog, will try and cover the stuff that's transpired of late.
First off, DisCoStu (from the PG2 Forums) was kind enough to offer to help out with updating the code for the PG2 Installer, and get it all set up for PeerBlock use.
A couple of minor nits existed with the initial installer-version released to test (on the PG2 Forums) - like not setting the WorkingDir on the shortcuts the installer created - but these issues were quickly fixed and reposted to the forum-thread, so the version that most people have been using of late should be pretty good as far as that stuff is concerned. It will even offer to copy over your old PG2 config-file if you've installed PG2 in the default "Program Files" directory, and offer to uninstall PG2 for you after you've installed PeerBlock if you're so inclined!
He's also made some spiffy custom graphics for the installer package, so it should look a bit nicer and more professional than it (or the original PG2 one) did previously. And the setup-files should have a rational name, so that you can tell which version is sitting there on your harddrive.
As part of the process of working on the installer, we had to come up with a versioning scheme for PeerBlock.
The "r33", "r52", etc., versions you're all used to seeing are currently based on the source-control revision used to generate that build of the program. This number is incremented every time a change is made ("committed") to the source code, and ends up being very similar to the "Build Number" associated with software like Windows.
The new version numbers for PeerBlock will be more standard, and should show how we're rapidly approaching a release worthy of being called 1.0. At this point, I'm calling the r52 version "leaked" to the forums 0.9.0.52.
The first number (the first 0) will mean the Major Version of the program, and is 0 right now since I consider us still in a Beta mode. It will be increased to 1 once we're at what I'd consider a stable release, and then will someday go to 2 only after extensive architectural changes to the tool. For example if we rewrite PeerBlock to run as a Windows Service instead of a basic app, we'd bump this up to version 2.
The second number (the 9) will be the Minor Release number, and will be incremented whenever new functionality is added to the software. So the official stable release of PeerBlock will be 1.0, then if we add new functionality to, say, allow you to right-click on a blocked entry and run a WhoIs query on it, or start displaying we'd bump up the version number to 1.1. I plan to make sure that these minor releases are extensively tested, so you can feel comfortable running new ones as soon as they're released.
The third number (the second 0) will be a Bugfix Release number. If any bugs are discovered in a Minor Release, the next release containing a fix for these bugs will increment this value; for example since we're currently at v0.9.0, the next release - containing a fix for the "app-crash during update" problem, and hopefully the "app-crash on exit" as well - will be v0.9.1. As time goes on, this will allow us to easily release bugfixes while continuing working on new features, without destabilizing publicly released versions with buggy new functionality.
The fourth and final number (the 52 in 0.9.0.52) will remain as the source-code rev; essentially the build-number of the program. This will make it easier to identify the source-code that goes with a particular release, for bugfixing purposes.
Google Code commit r53 contained DisCoStu's initial update of the installer code. Commit r54 was me updating the version-numbers; and r55 was DisCoStu's fix for the "no WorkingDir" issues, and included the new custom graphics for the installer.
For our future reference, when the r53 installer was run, it didn't associate a Working Directory value with the shortcuts it created. This meant that when PeerBlock created its peerblock.log file, or a peerblock.dmp file, the directory in which it was created could not be guaranteed. PeerBlock currently uses the Working Directory to decide this stuff, which since it wasn't set defaulted to the user's Desktop if they ran the shortcut from there, or C:\Windows\System if they ran it from somewhere else.
Commit r54 contains the new PeerBlock version-numbers, and should be referenced as a reminder as to which values need to be changed whenever we release a new version of PeerBlock. Note that we will of course need to pre-increment the build-number values, since as soon as we check-in that source-code change the build-number will change; this should be the last thing done prior to sending out a new release.
In addition to implementing the WorkingDir fix, commit r55 includes the new graphics for our installer: WizModernImage.bmp and WizModernSmallImage.bmp. We may want to update these once we come up with a unified "look and feel" to be shared among the program, the installer, and the website(s); but for now these look great to me.