New Enblend/Enfuse snapshot for Windows

Today I posted a new Enblend/Enfuse snapshot for Windows. The first question that came back from a user was “what changes did you incorporate against the version I have on my computer?“, to which I replied: “all changes that have been checked into the repository until this morning“. “Good and short answer, but not very helpful to me“. The hopefully helpful answer is longer and will help you help the next user in the same situation.

The repository keeps track of all changes in a log. Sourceforge has an automated mailing list that informs subscribers of changes. Builders read it to know when it is time to run the build process again. It is archived.To find out what bug fixes have have been incorporated, compare the CVS log against the dates at which the code was checked out to build the two versions you are comparing.

Sounds easy, right? not!

My snapshot is called CVS20080123, so that’s its checkout date. I’ve taken great care to start from scratch and to check out CVS at that date, so I know exactly what’s in there. I can guarantee for it. I don’t know what is in the binary on the user’s machine, I don’t know the codebase that was used to build it.

The first factor of ambiguity is the codebase time. An approximation is the file’s timestamp. But build time (the timestamp) is not the same as codebase time. Codebase time is predictible through the CVS check out, build time is not. I can check out now the exact status of the code at 19:00 of November 3 2006, for this we have CVS.

Another factor of ambiguity is change to the local codebase between checkout and build. I know which changes I did and I documented them for the other builders. The purpose of my build was to test building what what may eventually become a distribution. I do not what if any changes were applied to the codebase used to build the user’s binary.

The use of separate machines (and even separate people) for development and building is a good practice that avoids inadvertent pollution of the build with changes that are specific to the development machine. Earlier today Pablo had to revert hugin’s revision 2687 because some such code inadvertently got checked in, resulting in a broken build. If the build is done on a development machine, such a situation can go undetected until the bug in the binary hits the testers.

So to get back to the reason why the user asked the question: should he upgrade to the new snapshot or stay with his current binary? As a user, in doubt, always stick with the old one. As a tester: get the new one and test it!

You are free to download my snapshot and do (almost) what you want with it (subject to the GPL). It’s yours. My intention, with this post, is to avoid disappointment and frustration.

With new snapshots, be careful to:

• Not expect that everything in a ChangeLog works as advertised (this is why I did not include one).
• Keep a backup of your older, working software.
• Try the snapshot first in a non-critical setting, on copies, not originals.
• After the trials, take a few minutes to file a bug report to the mailing list.
• And if the new binary works for you, feel free to keep it beyond the short shelf-life of a snapshot. And remember to let the developers, the builders, the packagers, the translators, the manual-writers know: they will all be happy to know that their work is useful to you!