- A WilloWare product that has Minor Version 1 or above contains the New Installer (i.e. 12.1.36 has the New Installer, 12.0.35 does not).
- Minor Version 1 (and above) will require a “complete install” on each GP client using the EXE installation file.
- A change to the Minor Version number (i.e. 12.1.36 to 12.2.37) indicates the build includes database changes (i.e. new tables or table changes), so it requires logging-in as SA and completing the installation routines inside GP. No users, other than SA/DYNSA can be in GP during this process.
- Build Number changes (i.e. 12.1.36 to 12.1.37) has no database changes. No installation routine needs to run inside GP. The update can be installed with users logged-in, and the CNK can be pushed out using the GP Automated Updates utility.
Starting in October 2018, new builds of our software made after that date will begin including our New Installer, which will allow installing most updates without requiring running the complete installation routine (which requires getting all users out of Dynamics GP).
With the new Installer we will start incrementing the Minor Version Number when the new release of the software requires database changes (i.e. table or stored procedure changes). The Build Number will always increment with each new release.
Our release numbers have this format: 12.0.35
This is translates to:
Major Version: 12
Minor Version: 0
Build Number: 35
The Major Version corresponds to the Dynamics GP Major Version. For example, GP2013 is Major Version 12, so you must install a WilloWare Major Version 12 to match.
When the new installer is included in a product, the Minor Version will increment to 1 (i.e. 12.1.36). This is needed because the new installer is going to recognize Minor Version = 1 as its “base”.
Due to the Minor Version Number change, the first installation of a new build at Minor Version 1 (or above) will require a complete installation of the WilloWare product on each GP client. This means that the EXE installer must be run on each client, and that the CNK cannot be pushed out via Automated Updates. The EXE installer deletes the existing product DIC file from the GP client folder before placing the new CNK. When the Minor Version changes, Dynamics GP detect this and will not allow unchunking–the older DIC must be deleted first.
For all future releases the Minor Version will only change if the new release requires database changes (i.e. a new table, changes to a table, new or changed stored procedures, etc.). For example, 12.1.36 to 12.2.37 would indicate the following:
- For the first client (i.e. the server) you will need all users out of all Dynamics GP company databases, and you will need to log-in as SA and complete the installation process inside GP (which creates/updates SQL objects).
- You will then need to run the EXE installer on each client
Many new features, and bug fixes, do not require changes to the SQL database. For such changes the Minor Version will not change–only the Build Number will change. If the Minor Version does not change, such as going from 12.1.36 to 12.1.37, you will be able to install the new release on GP clients while there are users in the system, and if you use GP’s Automated Updates, you can push out the CNK to all clients using that utility.
As has always been the case, when logging-in our software checks the its version installed on the GP client against the version installed on the server. If the server has a newer build number it will alert the user that they are running an older version of our product, and then disable the product on that client. The rest of GP on that client will continue to function normally. This is a safety precaution to ensure an older client does not make changes to data that are incompatible with the newer build. Some of our products, such as Extended Lot Attributes and Manufacturing Data Archive have important data integrity controls on each client, so updates should be applied to clients as quickly as possible.
What was the reason for this change?
Previously, every release, regardless of how minor, required that all users be out of the system while the installation process ran. In many (most) cases, the only thing the installer did was update the build numbers in a tracking table. The requirement to have users out of the system made it very difficult for many of our customers to get updates installed.
The major benefit of this change is that it will now be possible to install most updates on GP clients while users are in the system.
Another change is that the old process required either (1) Updating all companies to the current build, or (2) Disabling the product in companies you did not want to update.
With the new installer, it will now be possible to test a new build in a Test Company while leaving the Live Company alone. To do this, create a separate GP client folder for the Test Client, install the new WilloWare build into that client folder, then log-in to the Test Company using the new Build. When you log-in to a Company with a WilloWare product containing the new installer, it automatically updates the Build Numbers in our tracking table (WCMP9000 in the Company Database). Note that it is important that the “test client” not be used to touch the live database because it will immediately update the Build Numbers in the Live Database causing the software to disable itself on all “older” GP Clients.
Build Number change only = can be installed with users in the system
Example: 12.0.35 to 12.0.36
Minor Version change = must run complete install process with all users out of GP. Full install from the EXE installation file must also be run on each client.
Example: 12.0.35 to 12.1.36
Example: 18.1.5 to 18.2.6