Object Version Number control - how do you do it?

Business Central/NAV Developers Forum
1

Over the years, I have used many different methods of controlling Object version numbers. The only thing I can say for sure about it, is that every implementation is different, and each requires a different method, but…

I am writing up some procedures, and I just wanted to hear from others how they update version numbers. Things like, do you un-tick the modified flag? Do you change the Time field (like Navision do) to something like 0:03:00:00. What do you do when you get cumulative version numbers, do you add that part in twice, or start again, eg NAV50,ADDON01,CustomMod01,ADDON03,CustomerMod04 vs NAV50,ADDON03,CustomerMod04.

I am not talking about object control VSS etc, just what you do with Navision version tags on the objects.

Also does your company have one fixed rule that everyone follows, or is it Client/Implementation dependent. Eg a client with 10 users, and one developer has less needs than an implementation with 3 databases, and 5 developers.

2

A very interesting question.

Over the years I’ve also been using several methods. But the last 4 years I’ve “frozen” my solutions to one method. The reason is that I’ve been running large international implementations. And when you run implementations with many different developers with different backgrounds from different companies, then you need a very strict and documented method. Basically we are following the same Dynamics NAV standard, as Microsoft applies to NAV.

In my method document I have the following section:

8.4 Version Control

When you are delivering a new version, you may have performed several modifications. You might have updated the objects with an improvement you obtained from Dynamics NAV. You might have an add-on that a created. You have your own core customizations. Plus, you might have changed the core customizations either as an update of the core or as a new.

You have a lot to keep track of. This collection of changed objects is unique and you need to know where all of these objects came from, and that is not all. Suppose, that installing an add-on changed an object and customizing it for the core version further changed it. Now, what will happen when Dynamics NAV releases yet another improvement that affects this object? How do you know which object can just be loaded on and which will take more work than that?

It is for these reasons that you need a method of Version Control. In Dynamics NAV, there are various tools built into C/SIDE that will help you with your version control.

8.4.1 Modification Flag

The Modification Flag is a kind of automatic version control. Whenever you change an object, the modification flag is automatically checked. The only way it is unchecked is if you deliberately uncheck it.

Do not uncheck the modification flag. This is only to be done as part of the release process.

8.4.2 Version Tags

The “version tags” are located in the Object List in the column called Version List. In order to work correctly with the Import Object utility within Dynamics NAV, the version tags require a fairly standardized format. Therefore, first we must cover how the Import Object utility uses the version tags.

The first version tag is usually the Dynamics NAV world wide base application. It consists of parts; if the version tag says NAVW13.10.01.25, the “NAV” is the product (Dynamics NAV), “W1” indicates that it is a world wide object, “3” is the major release, “.10” is the minor release, “.01” is the maintenance release (service pack), and the “.25” is the unreleased (but published) hot fix number. In all cases, before we publish a release or an improvement, we turn the Modification flag off. If a level is missing, for example, NAVW13.10, the numbers are left off. The major and minor release numbers are always present, but there may not be a service pack or hot fix as of yet. Since the import utility uses ASCII compare (character by character), NAVW13.10 is considered earlier than NAVW13.10.01.

8.4.2.1 Standard Dynamics NAV version tags

The version tags consist of:

  • Base Application version tags (first world wide, then localized NTR versions)
  • Other Dynamics NAV Product version tag (i.e. commerce portal)
  • Add-on version tags
  • ISS modifications version tag

Here are some other examples:

A released base application object from an NTR:

NAVW13.10

The same released base application object, with hot fix number 23:

NAVW13.10.00.23

The same object, with ISS core version 1.00:

NAVW13.10.00.23,ISSC1.00

8.4.2.2 ISS Usage

You must always leave the Dynamics NAV version tags alone! As you are making changes, you should leave the modification flag on, this is only done upon release of the object.

A new version is only created by the Dynamics NAV development team.

The development team works with major versions (i.e. ISSC2.00), minor versions (i.e. ISSC1.50), maintenance service packs or regular periodical releases (ISSC1.50**.01**).

8.4.2.2.1 Hot Fixes

Hot fixes does not get a version tag, but keeps the DIL# tag until the issue is included in a regular periodical release.

Versions with our “in-progress” tags (DIL#’s and initials) may never be released to production.

8.4.2.3 Standard ISS Core Version Tag Codes

The general ISS version tag to use is:

ISSC ISS World Wide Core

We do not put any version information into the time of the objects. But neither do we set it to a default like 12:00 like MS. And that’s basically because we have see that the ZUP file is not always updated correctly if the time of the object is not changed (even though the date is changed). And that has caused some forms not to work correctly.

The above not the only part in our methodology document describing the use of the version lists. Because whereas the normal version list is basically “out of the book”, then the other usage is more specialized. In my methodology a issue requiring development is called a Development Issue List Number - DIL#. And this number is used by our developers whenever they change an object.

8.1.1 Work In Progress Version Lists

You must now “lock” the object. This is done by adding the DIL# (i.e. #231) to the version list in the Development Database and your initials.

If the object is already locked, then you can not start doing your changes before the other user has “un-locked” the object again.

The DIL# is our reference to the DIL (Development Issue List) so that we know what changes was included when we install an update. Changes without a DIL# are not allowed. So make sure that you’ve registered it before starting the process.

Example on work in progress version list:

#4231-ABC

If you are modifying and existing object, then your WIP version is added to the existing version, i.e.:

NAVW13.00,#4421-ABC

If the object you are modifying contains non-released versions (versions with #), then add your new DIL# to the version list like:

NAVW13.00,#4421,#4434-ABC

Make sure that you never have more than one work-in-progress version at the time.

Installed purchased add-on packages, also in connection with add on-upgrades, must always carry the version from the vendor. But while “in-progress” (in the development, development-test and release databases, as well as in the training databases during user and release tests) they must also carry the DIL#, to allow us to filter on the objects that must be released. In the DIL system the developer must then manually maintain the correct version list of the object after the release.

Whenever the modifications are released to the production database, then the DIL# part of the version list is removed, and replaced with the version list code for the release (see the above description). The locking of the objects are removed when the DIL# is approved by the QA manager, and not until then our other developers are not allowed to use the objects. It’s out method to avoid using Visual Source Safe. And as long as you have a very active QA manager, then this works very good.

3

I use simpler version that Erick. Much of development is done in a separated database, when it’s done it’s moved to production database. So I don’t use object version for development.
I use a sequential object Number for example: cust001
Locking it’s done by request: Every Developer must has for a lock. Navision isn’t SourceSafe. [:)]

4

Hi David, we have a small developement team and so we use the version list. We stick with whatever is already there and append it. For example if the version list is NAVGB4.00 we append it with ,XX.01.00.01 where XX is the client +01.00.version of mod. So the first mod would look something like NAV4GB4.00,XX01.00.01. In the documentation section the same number appears along with the developers initials and synopsis of what has been done. If the object is in the 50000 range then only the XX01.00.01 etc will be in the version list. We dont touch the Modified field.

5

Basically this is much Like I would do on smaller customers.

When you make another mod, do you add another code (NAVGB4.00,XX01.00.01,XX02.00.01) or modify the last one (NAVGB4.00,XX02.00.01) I don’t mean if you make further mods to the existing mod, but if you make a completely new mod to an existing object.

Also do you create a new version number per object release, or is it updated per object number.

6

At some customer sites I use “a self made” version control (just 2 tables, header and lines).

In the header we store information about the changes which have to be made, who is in charge, date(s) of the changes etc. In the line we store the “old” object (before the object is going to be changed) grouped by table, from, report etc. After all objects are testet we “update” the version field by a function using the “number/code” from the header. We still have the old object number stored in the lines. Exporting the objects for the production system later is easy. Some installations allow to tranfer the objects direct into the production database(s) using the replicator.

What I like with this version control is that you can see immediatly all the recorded changes made in/on an object. And you still have the original object ready as it is stored within the “line” table.

I could make it “available” is somebody is interested.

7

What do you mean by simpler? That’s the same we do, just a bit more secure - which is required when you run an implementation with many developers (in many locations), with many users (in many locations). Development is done in the development database, development testing done in the dev-test database, when ready it’s moved to a release database (and the changed objects are released/unlocked in the development database). Then it’s copied to the ua-test database (user acceptance), and when the changes has been tested by the consultants and users, then it’s ready for release into the production database. Releases are managed as a new version, with a new version list tag and the modified tag is cleared.

8

I use a simpler version because the teams are smaller. Erik, your approach works quite well in large teams. But in a team with 2 people (the most common in Portugal) the object control can tends to be simpler.
I already saw some partners doing this kind of development directly in production database. (Don’t comment …) The concept in your approach it’s the same has Source Safe or other source code management.

9

Hi David, we just modify the last 2 digits i.e XX01.00.01 would then become XX01.00.02. For a new release, we create start again. For example if the standard version was NAVGB5 we would append and then start again at XX01.00.01 such as NAVGB5,XX01.00.01

Paul