I thought it might be of some interest to try to explain how we work in Dynamicweb when it comes to releasing new versions.
The difference between this release and previous releases, is that we do not update single solutions any longer. The standard-solutions will not have felt a difference, but our Custom-solutions might have. In previous releases, we had to register the path of each application-folder on every solution out there, in order to update them. This made it a very tiresome job for us. Not only was it necessary to update this list every time a new release was being set in motion, but also keeping track of which solutions that were to be excluded in the release was somewhat troublesome. A lot of manual work was being done and mistakes were more likely to happen because of this.
Now, however, things have changed and all because of the Update/Downgrade tool:
http://engage.dynamicweb-cms.com/Dynamicweb-CMS-389.aspx?ProductID=PROD219
Now we simply update the global application folder on each server, typically named "Application" (\\Servername\e$\Dynamicweb.net\Application), without the concern of how many custom-solutions are on the server. Every solution that has this application-folder as home-directory will then of course be updated. If the solution is custom and thereby has its own application-folder and is using the admin-folder of this Application-folder, it will automatically get the new DLLs from the global "Application" folder copied into its bin folder. This happens upon first backend login after an update.
This also means, that if you have locked your solution to another version, you will need to change this if you want your solution to be automatically updated. The option most common is "Latest", but this is to be regarded as the latest build that we have released on the servers. In fact there might be, and will be, hotfixes available that are newer than the "Latest". This is due to, that we do not overwrite the "Application" with hotfixes, but simply make them available for selection next the to global Application folder under another folder. The next hotfix will therefore be made available under the folder \\Servername\e$\Dynamicweb.net\Application(19.1.0.3).
We work with three different types of releases:
- Full Release (19.X.0.2)
The main focus is on new functionality, like the new eCommerce interface and functions in Dynamicweb 7.1. The release of a full release could take up to three months of preparations. When the final build is ready for release, it will overwrite the global Application-folder on each server, thereby updating the solutions that have chosen the "Latest" option from the version menu.
- Servicerelease (19.1.X.2)
There might be new functionality as well, but it will be smaller changes, like for instance the introduction of the Gallery module in 19.0.4.0. In general the purpose of a servicerelease is to fix a whole lot of bugs in one go. The release is similar to the Full release, but will not have to undergo the marketing preparations, like for instance Tech Reviews and such. This means that the period of which the release is underway is reduced heavily.
- Hotfix (19.1.0.X)
There is no official upper limit for the amount of bugs a hotfix can contain, but the whole point of a hotfix is to fix something quickly, because of its importance to the partners and customers. This limits the amount of fixes automatically. This also means that there could be hotfixes with just one bugfix, because it is a very urgent problem for some of our partners. Because of this, not all will recieve the hotfix like in the cases of Full Releases and Servicereleases. Instead we make the hotfix available for selection from the version menu and then send an email to the partner who has created a case regarding the bug(s), telling them that there is a fix available for them to use on the solution.