10

It is with a huge amount of pride and happiness I'm able to introduce Courier 2.5 today. This new version is a major step forward and is a result of the experiences and feedback we got from launching Courier 2.0 in May.

Courier is our take on a deployment tool for websites built on Umbraco. It's focused around 2 things:

• Easy access to performing a deploy directly from the umbraco backoffice, so even non-technical editors can do it
• Keeping track of the dependencies and resources needed for a deployed item to function

Courier 2.5, will be a free upgrade to Courier 2.0, and Courier 1.3 as well!

Looking back

It's not a long time since Courier 2.0 was released. It was received really positive, but as with everything, it was not a perfect fit to everyone. And it soon became apparent that 3 issues were widely reported:

• Timeouts due to too much data being transferred at a time
• Courier collecting tons of data, juts to transfer a single document
• No default support for uComponents and other community data types.

Major changes

Courier 2.5 solves those 3 common issues, along with another 80 bugfixes and smaller enhancements. Let's dive into the new big changes.

A dedicated task-manager

Pushing a big site with all its files and data is something that can take a while to do. First of all, it has to push all those changes across a webservice connection, and collect and process all the data on both ends. So with Courier 2.5, everything is handled by a taskmanager, which handles long running tasks in the background, queues tasks if something is currently being processed, and gives live feedback on the process of each task. This makes those long-running tasks rock-solid and at the same time provides status on how far your deployment is.

Support for uComponents and DAMP 2.0 built-in

Massive respect to both of these community projects. They have built up an amazing traction and is used on the majority of all Umbraco sites being developed today. So from version 2.5, Courier supports and understands these datatypes, and at the same time, we've added a ton of helpers and sample code to help other projects do the same, all available on the newly launched Courier Contrib project page (which I will blog about very soon)

Tweaking dependency collection

When you transfer a document, you don't just transfer that single document, Courier performs a analysis on the items you want to deploy, and then collect all the files and data for those items to function properly in their new environment.  A good example is that if you want to transfer a document, you would obviously also need to have its document type, template, css, images, macros and so on, transferred with it, or you would end up with a deployed page, that might not work.  We've done a lot of work to make sure that items transferred still work, but require fewer dependencies and are therefore faster to transfer. And we will continue to do that, even for minor releases.  

Finally, Courier 2.5 comes with a hugely refactored architecture, and simpler and more clear API to use, so for those who want to write extensions or run Courier from a console or WPF application, it has become much simpler. I will blog about these changes in the coming weeks as well.

Try it today

Courier 2.5 pre-release is available as a package file  and manual install files, and samples and documentation is found here. We will make sure to provide files and documentation on our.umbraco.org as soon as 2.5 is launched.

Launch discount

To celebrate the launch, we're for a limited time offering
Courier 2, Full version at a discounted price of just €99, that means you save €350

To get the discount, simply enter the discount code "fgdtt2237asds" on the Cart page, during checkout. Offer ends December 1st

We've decided to drop our plans of XSLT Support in v5 (it will be around forever in Umbraco 4!). For some this will cause some stir, so trust us that we didn't do this just for the fun of it.

XSLT has served us really well. In Umbraco 4 all published content is cached in one big XML document, making XSLT the obvious choice for manipulating the documents. For those who have mastered XSLT it's been a well-known and very powerful tool when making Umbraco sites. It's highly flexible, optimized for hierarchical content and blazingly fast.

XSLT in Umbraco has been there since the very start, in fact since version 1.0 that I made using classic ASP. Back then XML was all the rage, websites were simple and relatively small. And Microsoft loved XML. That was eight(!) years ago - remember those days?

Since then a lot of things has happened. We've learned that XML doesn't solves all problems, websites have become more sophisticated in their information architecture and new techniques have emerged. Sometimes you have to let go of your darlings to discover something new. And to be brutally honest, XSLT haven't been a happy marriage for most people. In fact, it repeatedly comes out as the number one disliked 'feature' of Umbraco whether you talk to front-end devs or .NET devs. It's time for a break-up from version 5. Here's why:

1. It's tough to learn, hard to master
   While powerful, XSLT is very complicated to master. There's simpler tools that does a better job in most cases and does a fine job in edge cases. XSLT only does a better job for the 1% who knows the very heart of it
2. It's not in tune with modern website architectures
   In the good ol' days, websites had a very strict IA. That was a perfect fit for Umbraco's hierarchical XML and XSLT templating. Times has changed. Today website structures are more fluent, more taxonomy based and more diversed (ground principles may be hierarchical but most content is tabular and relational). This doesn't make XML storage - thus XSLT processing - an obvious fit.
3. It would be slow
   Now that Umbraco 5 no longer stores data in a published XML, the core would need to simulate this in order for XSLT to work. It means converting data. And that means loosing the blazingly speed, that makes even haters accept XSLT today
4. The support from the mothership is non existing
   While we don't lay down flat when Microsoft change direction, it's no secret that the native XSLT processor in .NET is old and dated. It's many years since XSLT 2.0 saw the light of the day, but the .NET implementation is still based on 1.0 - which for instance doesn't know what a "date" is! We could grab a non-official XSLT implementation, but that would mean taking the responsibility for maintaining it and those resources could be used much, much better elsewhere.
5. The alternatives are better now
   The way we've implemented data access in v5 and combined with the razor view engine, means that making anything from basic navigations to complex taxonomy based lists is much simpler than even the most elegant XSLT. We'll be providing lots of guidance and examples in the editor to make it easy to get going fast.

Changing habits is never easy but even the most stubborn XSLT rebel alliance members I've talked to think the case is good. So do I, and remember that I liked XSLT so much that I added it to the core in the first place. The same joy I felt back then when the first result of XSLT processing inside Umbraco 1.0 appeared on my screen, I feel with Razor now. And when used together with the data wrapper called "Hive" in Umbraco 5, it's a thing of beauty and speed.

To help with the transitioning,  we've decided to make the razor tutorials on Umbraco.TV free. So what are you waiting for, really - go on, learn something new and build better websites tomorrow!