More and more partners are beginning to work with the update rollups. They find a lot of value in applying the latest application and platform fixes up front, instead of waiting for a customer to report those. Update rollups also simplify the way fixes are discovered and surfaced.
So with this blog post, we want to provide a more detailed picture of the update rollups, their purpose, and their usage scenarios so that you are aware of the rollup release process and components, and so that more of you start using them. We would also like to provide our look at how to adopt and use the update rollups within various stages of the implementation project lifecycle.
Update rollups are released monthly for Microsoft Dynamics NAV 2013 and Microsoft Dynamics NAV 2013 R2:
Released update rollups for Microsoft Dynamics NAV 2013 R2
Released update rollups for Microsoft Dynamics NAV 2013
An update rollup is a set of files that includes all hotfixes (application and platform) and regulatory features that have been released for the versions of Microsoft Dynamics NAV that are listed above.
They are cumulative, meaning that they include hotfixes and regulatory features that were released in the earlier update rollups for the specific product version.
Each rollup contains the following:
Hotfixes that are included in the update rollups do not always include translation. In that case, the translation for such changes are provided with the next RTM version of Microsoft Dynamics NAV (major releases or minor release). Regulatory features included in the rollup are almost always translated; however, in rare cases the translation is provided with the following monthly update rollup.
Update rollups are currently released for 10 countries: Australia, Germany, Denmark, France, Italy, North America (Canada, US, Mexico), Netherlands, New Zealand, Sweden, United Kingdom.
Local hotfixes for the following countries are currently not included in update rollups: Austria, Belgium, Switzerland, Spain, Finland, India, Iceland, Norway.
Maintenance. Applying rollups for the countries/regions where they are available.
If you have a version of the running application for which you would like to apply the update rollup, you can follow this high level flow:
Maintenance. Applying hotfixes for the countries where update rollups are not available.
For these cases the process of applying the hotfixes and regulatory updates is the same as it was before the UR concept was introduced, namely the changes relevant to all countries/regions (W1 changes) should be applied one by one.
However, URs can aid this process as well as you can obtain all W1 changes by downloading the latest W1 UR and merge them into your country version. You can find W1 URs by clicking at “Show additional information” and looking at their Fix Name which you can see when you download the UR:
Platform components are country independent, therefore the platform updates can also be obtained from W1 UR and deployed for any country/region-specific version of Microsoft Dynamics NAV.
URs are different from the major and minor releases. Every major and minor release contains new application and platform features and functionality as well as hotfixes, while the URs only contain hotfixes and regulatory updates. So when a major release or minor release has been released, we create a new branch for the next release and continue to maintain both branches.
Let’s dissect the process based on the Microsoft Dynamics NAV 2013 version as an example (see the illustration below).
When Microsoft Dynamics NAV 2013 version was released, we created a new branch for Microsoft Dynamics NAV 2013 R2 development. As we’ve been building Microsoft Dynamics NAV 2013 R2 functionality, we kept fixing Microsoft Dynamics NAV 2013 and kept releasing URs for it.
Relevant fixes from the Microsoft Dynamics NAV 2013 version were merged into the Microsoft Dynamics NAV 2013 R2 version in the course of its development. In many cases they had to be redesigned to fit the new code and new functionality of Microsoft Dynamics NAV 2013 R2.
Therefore, when Microsoft Dynamics NAV 2013 R2 was released, not all fixes included in the latest available Microsoft Dynamics NAV 2013 UR were included in it. The process of finding and merging relevant fixes into the latest branch is a continuous process, and there will be a certain lead time until the fixes from the releases are synchronized between branches. So, for instance, the majority of the fixes which were available in Microsoft Dynamics NAV 2013 UR7 were included into Microsoft Dynamics NAV 2013 R2 UR1, and the process of merging of relevant fixes will go on.
When considering upgrade or a new implementation of the new major release or minor release, we recommend that you always upgrade to (or start from) the latest available UR for it. If there is a particular hotfix which is available in the previous version of Microsoft Dynamics NAV, but it not yet available in the latest release, you can always request it to be merged there using the normal support process “How to create a new support case”. It is also always possible to only update the platform components with the updated ones coming from a corresponding UR (technical upgrade), although the best practice would be to keep the application objects updated to the latest UR as well.
Microsoft Dynamics NAV 2013 R2 hotfixes are also periodically merged into Microsoft Dynamics NAV 2013 and will be eventually available in the upcoming URs. Similarly, if there is a particular hotfix which is available in the current version of Microsoft Dynamics NAV, but it not yet available in the previous release, you can also request it to be merged there using the same support process “How to create a new support case”.
We will continue to release URs for the Microsoft Dynamics NAV 2013 release and future releases periodically, synchronizing relevant fixes between them over time.
Microsoft Dynamics NAV 2009 SP1 and Microsoft Dynamics NAV 2009 R2 are maintained following the old process - you can request hotfixes on case by case basis, no update rollups available for those product versions.
The following timeline illustrates the process.
It is highly recommended to implement the update rollups. We look forward to hearing your feedback and suggestions to how this process could be made more convenient for you to assess and absorb the changes.
Microsoft Dynamics NAV Team
Updated on January 16, 2014: We removed two sentences that were misleading around the upgrade rollups and the Upgrade Toolkit. We apologize for the confusion.
You are NOT making it easy for us to create addons for Microsoft Dynamics Nav...
I agree with Dennis. This is insane, plain and simple.
As requested with previous rollups, please release localized versions for all countries.
Merging a W1-version with a BE-version (for instance) is hell because diff-tools like WinDiff and Beyond Compare see every multilanguage caption as a difference. I wouldn't mind if the localized versions were delivered two months later than the W1. It'd still be better than delivering a project on the RTM version and then having to implement everything one by one. As it stands, merging these takes too long to justify the cost.
First of all, thanks for this good summarizon. One could complain about the update rollup processes, but not about the article itself!
Just one thing:
Support process “How to create a new support case”? Is there a link missing, several times in your article?
If you export all the language modules except ENU with option "Delete Language" first , you can afterwards export objects without all the multilanguage differences. When you have finished your merge and reimported the objects, you can then reimport the language layer files. That works perfectly and saves hours of time spent with merging.
Great discussion! Thank you for your comments and for sharing your view.
@Dennis - would you please elaborate? What is causing troubles? Anything we could do to ease this process for Add-on providers?
@Jens - I found your points on another Blog post:
1. Fixes: Real fixes of bugs, no new features or changing of the code base structure on the fly. All this in rollups, that'll be fine. What's not ok is when captions are reset to english because you've changed the W1 caption... this is a major pain for every user of localized versions, that'll be most of us NAV partners. Or you make major changes in (for example) CU 12. This is a real pain for partners with Add-Ons.
2. Feature Updates: If it has to be... but then based on a easily to find source base, or it's a merge nightmare.
//DMC: We are searching for the feedback like this, things which would ease the process of rollups (and new versions) adoption. Could you please give me more info on the situation with captions being reset if you get a chance? In which version/objects/localization it happened?
CU12 was indeed refactored significantly in NAV 2013 R2 RTM release, it was a real pain maintaining it in the past. It will take time to learn the updated structure, however it should be more easily mergeable and extendable in the future. There is a White Paper available in the NAV 2013 R2 Readiness Library on the Partner Source which explains the details of this refactoring (PS is under reconstruction currently - I'll try to find the link as soon as it is available again).
// Finding a source base - how would you like it to be exposed? What would you expect to see in the source base(s)?
@Natalie - thank you! The link will be added as soon as PS is back in its full glory!
@Vincent and Kai - yes, exporting language modules with "Delete Language" flag would indeed remove MLCaptions for that language from the code, so this should help. We are also aware that dealing with MLCaptions in this way is tricky (to say the least), so we are looking at the ways to improve this experience.
In the article it is said that "Hotfixes that are included in the update rollups do not always include translation."
Why is that?
Where is the problem with translating the missing MLCaptions? I mean I can do it! My only problem is supposably with next Update Rollup 3 they will be overwritten if I’m not really carefully. That is why I recently submitted about 23 DEU-Caption with English Content to the Microsoft Support regarding Dynamics NAV 2013 R2 release to Update Rollup 2.
It is a pain to update multiple client installs with rollups. I know you could build a ClickOnce installer or install via policies... But for small customers with 5-10 clients it could be solved easier:
It would be nice if a small update utility was included. One which was initiated by the NAV Windows client when it was started and found that the server had a newer build than the client...
Simply exit NAV, call the updater which would then download (the rollup package from a pre-defined path/URL) and update the client to the same platform build as the server and then restart the NAV client...
Thanks for the tip. I'll be trying that as soon as possible !
regarding the code base for merges... I would assume that you're using a revision control system inhouse. I assume quite a lot of partners do likewise now. To set one up you need the real base versions (the RTMs?) to have a base to apply changes against. When a rollup update gets released, you need to add the changes to your "msft" tree, to have starting points for the releases you do with your AddOn. Also, for the release to customers, you merge the changeset of the rollup update into the customer's tree.
So far so workable, if it weren't for a few problems:
1. What's the "branch" revision for a new version of NAV? We can't know, we could perhaps find out afterwards. So, we have a problem setting up a correct version tree to branch out from (example: NAV20123 -> NAV2013R2 has a code base somewhere between RU5 and RU6).
2. For the localizations you also need the true "branch" revision. Same problem, essentially, but even more annoying due to the captions problem.
If you're maintaining AddOns, you have to ensure that it runs as advertised on all the versions and localizations you support (and from 2013 on, all the rollups). That is quite a task in itself (now). If you offer a "merge" service to ease the integration of your AddOn into the customer's database, you would also need the correct base tree to have a chance of doing the merge in reasonable time. Keeping the whole thing working requires a lot of work and discipline. The maintenance amount is so high that the fact that you actually want to develop new features gets somehow thrown under the bus.
So, anything that eases the maintenance of the rollups/localizations/AddOns would help getting me back to actually do some development.
with best regards
I created a repository in which I checked in below versions of which I can branch and compare any version of our implementation. The way I did it was to create a full text export, split the individual objects, but also strip Date/Time/Modified and Version List. That way you get clean compare of code changes and not "version" changes which might conflict when trying to make a merge with another countries implementation.
master > 3.0.10008
master > 3.1.10750
master > 3.6.11353
master > 3.7.13643
master > 3.7.16172 > 3.7.19516
master > 4.0.19365
master > 4.1.21666
master > 4.2.22100 > 4.3.25143
master > 5.0.24199
master > 5.0.26084
master > 6.0.27808
master > 6.0.29626
master > 6.0.32012
master > 7.0.33781
master > 7.0.34688
master > 7.0.34902
master > 7.0.35026
master > 7.0.35201
master > 7.0.35345 > 7.0.35488 > 7.0.35670 > 7.0.35782
master > 7.1.35473 > 7.1.35701 > 7.1.35764 > 7.1.35800
Using the "for personal use" free SourceTree client you can easily do a blame or a log to see what version changes what and who changed it.
Setting up a remote on visualstudio.com and you are easily set to work from home or office on the same codebase.
I agree with Gert Lynge. The major reason to why we don't update regulary with UR:s is that we need to "reinstall" all the clients which is a time consuming process.
Another reason is that it will be harder to maintain from a developer perspective. Correct me if I'm wrong but each UR is a new build? This means if we have several customers on different builds we have to maintain in our own developing environment (some times you can't cross objects from different builds).
I would appreciate a blog post on how to easy install a UR on customer site which has a lot of clients and some tips and tricks about how to easy maintain several builds at our own site.
@ Dmitry Chadayev
We have 4+ addons we offer in DK and W1 versions.
Lets look at one of them:
We have modified the following standard objects:
To make installation as easy as possible for our Partners we always want to be able to provide the latest version of each object.
Every month when you release a new RollUp we have to move our addon-code into every object you have changed.
(Please note - a modified Version List is also a change)
We are wasting time moving code!!
And that is not all.
We also have to support the new RollUp versions for X months.
Lets say I have a new feature for my addon that require a modification to table 112.
I now have to modify every unique table 112 I have in my system (W1 and DK versions)
How many extra versions of table 112 do you think I will have to modify in 6 months?
You could say - you dont need to support all those RollUps - just delete them after x months.
But if we make a great new feature or a bug-fix for our addon and a customer with RollUp 1 only would like to get it - then he should be able to get RollUp 1 objects from us for a quick install...
We are wasting time supporting too many versions!!!
Are you really sure we need a RollUp every Month??
Have fun Mr. Elvis ;)
Daniel, Gert, Jens, Sebastian, Capone and Dennis - Thank you for all this great input! This is really helpful and I can certainly see, that keeping up with the rollups can be a big infrastructural challenge.
Although it is interesting to note that this has become more prominent when we introduced *the notion* of an update rollup.
In the past, we were releasing application hotfixes and regulatory updates separately on the Partner Source. They would pile up there until someone would bump into an issue and then they would have to search for a specific hotfix among dozens of titles in the library. There would even be hotfixes which intersect with each other! If a regulatory feature would be touching the objects which are already patched by a hotfix, you (and we) would have to search for those hotfixes and integrate them into the regulatory feature. So the base application objects would also change back then, and the add-ons would be tricky to apply in those times too. The base version would be somewhat unpredictable (well... unless you don't apply any fixes at all).
With the rollups we removed the complexity of cherry-picking hotfixes and RegFs - we are shipping a complete version every month. New implementations can start on the version which is compliant with local laws and has less issues in it. Also when a new release comes out - there is less merging required, as the code of the hotfixes and regulatory features is already merged.
But with the rising update rollups awareness - customers' and partners' expectations are also rising, as you correctly pointing out. It requires better tooling, structure, source data, source control and actual merging. You are absolutely right - it is a lot of versions to maintain *today*. As we improve and optimize the way we absorb the rollups - eventually there will be less fragmentation in the versions the customers will be running. Until that time - I can assure you that we are looking at all possible options to make this process easier for you, you'll be seeing more done in this area. Therefore please keep up the constructive feedback like this. It is ending up in the right hands! :)
Dmitry (aka Mr. Elvis ;))
Microsoft Dynamics NAV Team
I don't think that there will be less fragmentation in the versions the customers are running. We are already getting requests from our customers (other MBSPs) for all Update Rollup versions that exist, and if this continues the way it is now the day will come when I will have several requests for our addons on my desk all at the same time, one for Rollup 3, the next Rollup 11 , Rollup 23...etc, depending on when the NAV rollout actually took place and if the partner who is taking care of the customer updated the site installation in the meantime.
Since NAV 2013, NAV 2013 R2 and NAV 8 "Crete" and NAV 8 R2 all will have their own rollup product line to handle, the amount of work will triple or even quadruple every month until the support for NAV 2013 ends.
Supporting all the different technical builds will also be a big issue. In our case, Rollup 8 was the first version which could not be compiled with the RTM build due to a new DotNet-Method in the Excel Buffer, but even before this there was a change in the compiler which had an impact on the way the coding in a page object was checked. This led to the effect that the RTM build compiled the page without problems but the compiler of the rollup version did not. So to really make sure that the objects will be usable straight away there is no alternative but to compile them with the corresponding build.