It is already more than a week since Sitecore 8.2 was silently deployed to the Sitecore Developer Portal.
It comes loaded with exciting new features like Dependency Injection (check Kam's excellent blog post); support for the new optional Publishing Service (read more about it on Jon's blog); a new revised Path Analyzer; improved Experience Editor; OData support in the Sitecore Services Client and much more. It comes with so many goodies (and some breaking changes) that it almost feels like it should have been a major release.
So you want to upgrade and start using it straight away. You might simply install a new version of Sitecore and deploy your solution on it. This is my recommended approach whenever possible. Alternatively you may choose to download the .update package from the portal.
It may then come as a shock to you that the update package is about 1Gb in size. It is strange as an entire unpacked Sitecore application is more or less that size. It turns out with 8.2 they have simplified the upgrade process. That would be really very good news...
This improvement consists on shipping one single (slightly massive) update package that can upgrade any version of Sitecore 8.1 to 8.2. How is this achieved? If you look inside the update package you will find... guess... 4 update packages!!
Essentially each of those packages knows how to upgrade from a different revision of 8.1. So when you install the massive update package, it checks the version you are running and chooses the correct subpackage. This is obviously not something the update installation wizard knows how to do, so they had to add that functionality. This is why, before you actually install the update package, you have to install a traditional Sitecore package to upgrade the installation wizard first.
Actually this is not the only prep work you have to do. You also need the Configuration files for upgrade, which contrary to its description Download this package if you need only web.config adn App_config files it also contains two SQL scripts you need to run. One is for master, core and web the other for the reporting.
Returning to the update package we now know that actually only one of the files is needed. So we could extract the correct subpackage and install that instead. If you are working on a remote server you don't have to move around 1Gb files, but only 240/280 (depending on the version).
There a few other interesting points though: 240Mb still seems a rather large file. I would expect this file to only contain the changes, new files/items, modified files/items and the list of files/items to delete. I found two potential reasons for the file to be so big:
- The file contains things that have not changed. For example, all the icon collection of Sitecore is packed in several zips (one per category). The zips have changed between versions (by a handful of bytes) but the contents have not. This accounts for at least 80Mb. There are other zips in the /sitecore/shell/ClientBin folder which cause the same issue.
- The package keeps a hash of the original files to be able to detect any collisions when the original file has been modified and avoid overwriting file changes. This is a great idea. However it looks like the entire contents of the old file are also stored there. This means that any changed file is stored twice in the package, once for the old version, and again for the new version.
Put those two things together and you end up with a slightly bewildering consequence: the size of the update package is as big as the entire zipped Sitecore installation.
There are other peculiar things during an update. Grab a blank copy of 8.1 (I used update 2), and run the update package to make it 8.2. When you first analyze the package you are notified of 119 conflicts.
I am not sure how a dedicated update package for that particular revision can have so many conflicts with a fresh installation. The challenge is that if you genuinely have conflicts they are going to be buried in there and you will not be aware of them.
If we look in more detail the majority of the conflicts are trivial. Item to be deleted is in use and Template to be deleted is in use occur 89 and 3 times. Those happen when the item has references and items exists based on the template. This is not surprising; I would almost say it is not worth showing. More intriguing are the Item not found and Field has been modified or Item has been moved.
The update process itself takes a little while, so grab a coffee or your favourite drink, let it run, and then marvel at all the new exciting features!