Hi Can anybody tell me what is the best way to maintain the Versionlist-field in the Objectdesigner ? I know that it is used to keep track of which elements have been modified, but what do you actually write in this field ? How do you maintain the field in a logical way ? All suggestions are welcome … /Lars
Hi! As we do all development in house, we use it this way: All development is done in certain project where we define a Project-Code to be used in VL. e.g. third re-engineering/re-implementation of Navision: AO3.00 All objects, that were added or modified within this project are marked with AO3.00 in the VL until we go “live” with the new system. When ever objects have to be added or modified after the system-start, we will “count up” the VL, e.g. minor fix: old VL: AO3.00 new VL: AO3.00.01 major fix: old VL: AO3.00 new VL: AO3.01 new AddOn: old VL: AO3.02.01 new VL: AO3.02.01,EDI1.00 ... This is very similar to the “standard-use”. In addition to this, the history of all changes is documented in the Documentation-Trigger, where the related VL is listed, too. (This documentation is also exported to a special Navision-tool, where the detailed object-history is shown). We save all changed objects per day, so we can keep track of the history of all objects, and - if necessary - restore an older version. Regards, Jörg
I allways keep the original version-list. If changes are made in an object the versionlist will be “NAVW13.60.00.24,ffo030929” indicating “change made by ffo (my company) on september 29th 2003”. Within the object itself I write the documentation. We tried the “project-solution” as Joerg mentions; skipped it as an object may be part of several projects. And instead of distinguishing between minor and major fixes we call a change a change. If I changed a standard object, there is a check-mark in the Modified-column. If I created the object (Id in 50000…99999) I remove the check-mark. If there is a check-mark i presume that a change is made by another person/company. Now it is very easy for me to filter out all modified objects. I allways have the original objects (not data!) in my local database. By this I can service my customers via phone and mail. Less cost, more income. And if there is a mismatch between my version and the customers “somone else ****ed the system up”. The best way? Don’t know - this is my way and it works. For me, that is.
Hello, We do this as follows: If we were to modify the Sales Line table in 3.70 this would go: NAVW13.70.00.08 → NAVW13.70.00.08,COSL370.01 (COSL is our company abbreviation) If we did another big mod,this would be: NAVW13.70.00.08,COSL370.02 A small mod/fix would be: NAVW13.70.00.08,COSL370.01.1 As per previous replies, we do not put in ‘project referrences’, as one object may relate to many objects. This is documented in the code. The modify flag is left as ‘true’ (So we can filter on it) but re-set the time field to an agreed fixed time (Like MBS using 12 AM), so we know if we were the last people to modify it. We also modify & release codeunit 1 as per MBS, with each new release and include the Navision version ref (370) in our ref in case we are asked to look at a mod at a later date. (E.g. The object was written in a 360 enviroment, but the customer is now on 370). We keep full sets of the customer objects, export the old ones and archive them off (So if we ever need to back things out, we just load the old fob), load the new fob into the database, & keep a copy of the new fob in a release folder. This works well for us as an NSC, but an end user might find it easier/better to do do things differently. One thing, don’t put in ‘Version’, ‘Ver.’ or ‘V’ in a version ref - It is blindingly obvious what it is, so why clutter the field by add it! People who do this annoy me![}:)]
We do these somewhat differently than everyone above, but closely related to Joerg’s version. We use developer initals and the developers sets his own version tag (OM3.02). Each developer starts the modifications by doing these steps and the developer makes his own versions. As the developer has new versions the documentation trigger and version list (OM3.02–> OM3.03) are updated. We keep track of whom is working on what by keeping those objects flagged as being modified until they are ready to go live. We can be assured that if the modify flag is on the version list will reflect the developer and the documentation trigger will provide the explanation for that version along with the dates in process. Works fairly well. It is limiting if multiple developers need to make updates to the same object but it doesn’t happen a whole lot b/c were on unrelated projects. Owen
Edward- Your recommendations sound great, but I don’t understand the statement “We also modify & release codeunit 1 as per MBS.” I’ve never heard of this, so I’m hoping you can provide a little insight. Thanks
quote:
Originally posted by AlanK
Your recommendations sound great, but I don’t understand the statement “We also modify & release codeunit 1 as per MBS.” I’ve never heard of this, so I’m hoping you can provide a little insight.
I guess the modificatin is done in function ApplicationVersion()…
Hello, Anfinnur is correct. We have our own additional application version function in codeunit 1. This combines with the standard Navision one, and is displayed on the main menu when you open the database. Most customers cannot modify this codeunit, so it is pretty secure. This also saves time, so when the client complains that ‘the fix isn’t working’ [}:)], you can open the database and point out that they haven’t loaded it yet…[:D]
Hello, we use it to mark our own developments with two letters and leave original versionnumber untouched. So we can filter which object do a certain job.