When the pre-release is done, you will receive a link to it at the address you specify above. The address will not be used for anything except to send you that one email.

Click here for the latest changes in the 7.2 branch.

Click here for the latest changes in the 8.0 branch.

The version numbers have changed! (as of February 1, 2006). The version that was called 7.1 is now called 7.2, because we're shipping 7.1.15 as 7.2.0 (because it's a fairly significant change). The version that was called 7.2 is now called 8.0.

Notes about the use of pre-release versions:

Most software companies do not have pre-releases; they are fairly unique to us. They are user-requested builds of Sawmill which are built on demand, from the very latest snapshot of our internal source code. You request them from our web form ( http://sawmill.net/prerelease.html ), and they are built, through a fully automated process, on the appropriate platform, packaged up, and sent to you via email.

Because pre-releases are fully automated, and are built from the latest snapshot, they allow us to immediately send you new features which have been implemented in Sawmill, immediately after they are implemented. This is nice in some ways, because we can get bug fixes out to customers in a matter of minutes.

But it has serious downsides, too. The major one is that these are not production quality releases. They typically have bugs which will be detected and fixed during final Q/A, but which naturally cannot be fixed for pre-releases, because they are being sliced from the active development code. Therefore, pre-releases cannot be trusted to be bug-free.

A second downside is that on Windows, pre-releases come as a ZIP file rather than an installer. Since we do not have a fully automated way of creating a Windows installer (it's 90% automated, but it still requires a small amount of human involvement), we cannot create a Windows installer with a pre-release. Therefore, on Windows, pre-releases ship as ZIP files. This means that they cannot be used to "patch" existing production installs; you need to wait for the next production release before you can update your existing production installation.

For the most part, that's a good thing; since pre-releases are not stable, they shouldn't be trusted as replacements for the production release anyway, and should be installed off to the side somewhere, and run there (without touching the production release). If it works, great; you can continue to run it from its "off to the side" location until the next production release makes the changes official.

So, "best practice" is to install a pre-release in a separate directory, not replacing your production version, and then use the pre-release (if it works) until the next production release brings an official implementation of whatever you needed from the pre-release. This will prevent problems with installing future production versions on Windows; as long as you don't overwrite your current production installation with the pre-release, it won't cause any problems on your next production upgrade.