Thursday, March 17, 2011

Your Project Team Should Use the Same Build!

A post at AUGI prompted me to reply and I decide to make it a post here too after discovering I haven't written about this here yet.

The essence of the question is, "Does it matter if we are using different builds in our firm?"

Short answer is...

A project team should be using the same build to work on shared project files. For example, an architecture team working on a "shell" project file and "interior/core/circulation" model (2 models) should all be using the same build. Anyone who is going to contribute to the project should be using the same build as the rest of the team.

Stretching the short answer...

Technically, you could have different builds deployed but avoid letting it happen within the same team. If a new person gets added to the team...pause and think about the build.

Personally I think it would be nice if the software would mention that situation when a file is opened. In an earlier post here on my blog I mentioned that David Baldacchino and David Kingham have written such a feature into their AutoHotKey Local File scripts. They've also shared their work here in another thread at AUGI (DK's Script & DB's Script).

Think of it this way, they don't issue new builds because they feel like it or just because a couple months went by and they are restless. They issue them because they've fixed stuff, stuff that has been aggravating users enough to report them and press for fixes. They also fix stuff that they couldn't deal with prior to other releases or builds getting issued.

When I use an old build while the rest of the team is using the new build my version can introduce a problem that the newer build fixes. When I get out of the project the rest of the team interacting with the project "fixes" what my build "broke". When I come back in and start using my build I can reintroduce the problem, starting the cycle over again. Much like passing a cold around the office "forever".

At its most harmless...nothing happens and we never notice. At its worst we have local/central file corruption and problems. How severe depends on how big the fixes are in the newer build.

I should also add that Revit doesn't have any problem opening files that use different builds as long as they are the same version, such as RAC 2011. The file format changes with a new "version". Builds are incremental changes to the code within a version.

How do you know what build you are using? Click the smallish arrow next the HELP button, then click About. Revit displays the build number in the upper right corner of the screen that appears.

1 comment:

TerribleTim said...

But hey, since we still don't have a "save back" feature, at least we don't have to worry about members using different versions, right? :-P