Earlier this year I worked with a third party product for Dynamics GP. I believe it is all .NET, so it had a few DLLs in the GP AddIns folder, and a few additional DLLs that were used by an external application independent of GP.
While testing, we identified a few bugs. While communicating with the ISV, we were asked which version we had installed. I checked the DLLs and found the following version number.
10.0.0.0
Hmm, that's a little unusual, but okay, I told them we were using version 10.
Their reply was not THAT version number, but the date time stamp on the DLL files that we had installed.
Say what?
They asked us to ignore the actual version number on their software and report the date and time that was showing for their DLL files. For their commercial software product. That they sell. As a software development firm.
Let's just say I was surprised. Any developer that has used Visual Studio should be familiar with the window that lets you set and increment version numbers. And having developed, installed, and used hundreds and hundreds of software applications, I thought that software versioning was a no brainer and one of the most basic organizational practices that a developer should be using.
To this day, that ISV still refuses to use version numbers on their software. Dozens of releases and updates and bug fixes and changes later, their files are steadfastly stamped with version 10.0.0.0. We never know what "version" we are using, and every time we have a support case with them, they ask us what time stamp we have, and their only solution is to try and send us files with a newer time stamp. I wish I were kidding, because it's a confusing mess to deal with updates from them.
So that's a great lesson on how not to (not) use versioning for your Dynamics GP customizations, integrations, VS Tools AddIns, and software.
So how should you version your Dynamics GP customizations or software?
First, let's agree that you should definitely version your software. Any method is better than no method.
As for version numbering, different people and organizations have different practices, but here's the system I've adopted.
I typically use a format of "1.23". Even though Visual Studio has 4 separate values, I combine values 2 and 3 to make the number more readable, and don't typically use the 4th value. I like 1.23 much better than 1.2.3, but as you'll see shortly, this has a potential downside.
I start with a version 1.00. If I have some minor bug fixes, I'll increment to 1.01, 1.02, 1.03, etc.
If I add a new feature or fundamentally change some functionality, I'll increment the second digit, such as 1.10, 1.20.
As the version numbers increase, I personally try and avoid going above 9 for the second and third digit. I did it once, and it ended up being quite confusing. Since I combine the 2nd and 3rd version segments, how do I represent version 1.1.0 vs. 1.10.0? If I use 1.10, do I use 1.100 for version 10? It doesn't work well with my typical version numbering.
When the customer upgrades to a new version of GP, I'll typically increase the major version number, so I'll go from 1.23 to a fresh 2.00.
However, in cases where I am developing software for use with multiple GP versions, like the software that I sell, I now include the GP version in my software version number. So I'll have 10.1.23, 11.1.23, and 12.1.23. That way I can know that the customer has the correct version for their version of GP, and during support calls, I can see my version number and know which version of GP the customer is using without having to ask or look it up.
In a new twist, last week I released a web service that integrates with GP. As the customer tested, they wanted rapid bug fixes, so I would fix a bug or two and push a new release multiple times in a single day. My version numbers were quickly escalating, so I enlisted the fourth version number in Visual Studio. So for minor updates or bug fixes, my version numbers would increment like 2.23.1, 2.23.2, etc. It has worked well so far and hasn't been inconvenient or confusing.
But even with these frequent updates, I always increment the version number. It keeps things organized, avoids confusion, and every customer and consultant I have worked with understands the concept of version numbers, so the practice makes communication about updates and new versions easier.
For customizations or integrations with a visible window, I always display the version number on the form. Never make your customer search for a version number when they need support or when they need to check that they are on the latest version. Just always add it to at least one of your forms or to Help -> About--it takes 2 minutes and it will make life easier for everyone.
In this case, the form is displaying 12.1.2.5 because that is the actual version value from the .NET application, but I would refer to it as version 1.25 for GP 2013.
For Modifier and VBA customizations, I have sometimes added the version to the GP windows.
So far I've accomplished this with a simple text label in Modifier that I have to manually change with each release. It isn't fancy, but it's simple and easy.
Whatever you do, please, please, please do not rely on file date time stamps to version your software.
Steve Endow is a Microsoft MVP for Dynamics GP and a Dynamics
GP Certified IT Professional in Los Angeles. He is the owner of Precipio
Services, which provides Dynamics GP integrations, customizations, and
automation solutions.
No comments:
Post a Comment