The Importance of Version Tags in Dynamics NAV Objects
Every object in Microsoft Dynamics NAV (Navision) has a version tag. You’ve probably seen them in the Object Designer; they look kind of like this:
NAVW17.00.00.35026,NAVNA7.00.00.35026,JM7.0.18,SE0.55.12,AP7.00.006
That one comes from the Sales Header table for a customer running NAV 2013 who has several add-ons and customizations installed. It’s awfully long, isn’t it? I’ll try to break it down and explain what these all mean.
You’ll notice that there are several commas in there. The general rule of NAV development is that every group of people that touches an object leaves its own stamp on it in the version tag, and the tags are separated by commas.
The first part of the tag is “NAVW17.00.00.35026.” The “NAVW1” denotes that this object was modified by the core NAV development team. The “7.00.00” part denotes that this object was last modified as a part of the NAV 2013 initial release. Objects modified for NAV 2013 R2 are tagged as “7.10.00,” and objects modified for NAV 2009 R2 are tagged as “6.00.10;” the core team conforms to the standard major.minor.more minor format generally used in software development to denote releases. The “.35026” marks that this object has been touched by one of the hotfixes that Microsoft releases periodically; those are all marked chronologically so that we can tell what’s been applied. Every object in the base NAV system has a “NAVW1” tag telling you when it was last touched by the core development team.
The next part of the tag is “NAVNA7.00.00.35026.” The “NAVNA” denotes that this object was touched by the North American localization team. (Other regions have their own tags; feel free to get a whole bunch of different localizations of NAV together and play Localization Team Tag Bingo.) Again, the “7.00.00” tag tells us that it was modified for the 2013 release of NAV, and the “.35026” tells us that the object was changed as a part of a hotfix. The North American localization team (and presumably the others as well) use the same major.minor.more minor versioning format as the core team to denote release changes.
The “JM7.0.18,SE0.55.12”section of the tag is used to denote that two different add-ons have touched this object. This particular customer is using Cost Control Software’s Job Manager add-on (the “JM7.0.18” tag) and also Lanham and Associates’ E-Ship add-on (the “SE0.55.12” tag). Since there were two different add-ons for this customer, the code changes had to be merged. I was the developer who did the merging of the code, and so I had to decide which tag went first and which tag went second. (and for a few objects, third; this is a customer with a lot of add-ons running together). The important thing here is that I needed to be consistent with which add-on tag came first, then second, then third, and fourth, etc. There’s no rule for determining which add-on wins and has its tag go first.
The last part of the version tag is “AP7.00.006.” This is the ArcherPoint tag, meaning that we changed the object per a customer request, and they’ve approved the changes for use in production. The “AP” is our initials, and the “7.00” is the version of NAV we’re working with. The “.006” means that this was changed in our sixth release for the customer, not the sixth modification we’ve made to the object. (We do make notes in the Documentation trigger of the object for each change we make to the object, but those are the subject of a different blog entry.) In my time in the field, I’ve seen other NAV consultancies use similar tags for their changes. When we come across them, standard ArcherPoint policy is to try to leave them intact and append our tag to the end of the object if possible.
I will also tag objects that I’m working on for an unreleased project by appending my initials and something else to the version tag. If I’m modifying the object as part of a support ticket, I try to use the number from our internal ticketing system, like “TH1234,” and if I’m modifying it for a project, I try to use the number of the task from our project management system, like “TH12345.” If I’m working on the same object for multiple customer requests, I add a tag for each request; it helps me track which objects belong to what project, and it lets me know that I may have to de-merge some code from project B to get the object moved into a testing environment for project A.
Sometimes, we run out of space in version tags. This happens more often now than it used to, since Microsoft started adding six-character hotfix numbers to the worldwide release tag and to the localization release tag. When this happens, we try to keep the tags as intact as possible. The first things to go are the tags from other consultancies, assuming that they’re not still working with the customer. The next things to go are the commas that separate the individual pieces of the tag. After that, we have some hard choices about what to drop; we’re still hashing that out internally.
So, that’s an explanation of what the object tags mean and how they are used. Hopefully you can use it to understand what’s been done to an object.
For more information or assistance with NAV development, read more ArcherPoint developer blogs or contact ArcherPoint.
SPECIAL STREET FIGHTER UPDATE: I didn’t get to go to Las Vegas for the Evo Street Fighter IV championships, but I did at least watch it streamed online with some friends. Watching Luffy win the tournament with his Rose has encouraged me to start experimenting with Rose myself; I’ll see what I can do with her. Normally, I main Blanka, so I like how Rose has some gimmicky stuff with Ultra 2 and her fireball reflection/absorption. I also like having a relatively easy super cancel from Soul Spiral; maybe Rose will end up as my go-to alternate character.