Respecting legacy, paving the way for the future

Monday, January 07, 2013 by Niels Hartvig

Today

Happy New Year!

I can’t remember the last time I’ve been this excited about getting back to work after a holiday. While 2012 in hindsight was about getting lost and messing up, followed by soul searching, finding back to the roots and coming out healthy and strongly of a crisis, this year seems much more bright, especially as we can start building on what we learned last year.

There’s a lot of positive change coming to the Umbraco project over the next twelve months, including two new major versions, followed by the Umbraco-as-a-Service cloud offering we’ve been working on for quite a while here in the HQ. The overall agenda for all three projects, is getting back to the roots of making Umbraco a powerful, yet simple tool to build websites.

The Umbraco Roots (photo by Douglas Robar)

Two new major versions in the horizon - what does that really mean?
A major version of a piece of software can always sound scary and in the world of Umbraco - with v5 in hindsight - it could be nothing short of a horror movie. However, in the core team we’re doing everything we can to make it G rated.

First of all, a new major version doesn’t have to mean major changes - and in particular nothing like v5 brought. Been there, done that, got the t-shirt and not only didn’t it fit, it was also damn ugly. One of the decisions following CodeGarden and the v5 aftermath was to move our versioning to SemVer. It means that if we add changes to the core that could break (but might not for all), we need to bump up the version number. With the coming v6, that’s what we might do.

V6 for dummies

Umbraco 6 is in its final stage of testing and while it looks and behaves just like the Umbraco you know well, it brings a completely new CRUD API. Fancy as it may sound, it simply means that the way that Umbraco creates and updates its data has been completely re-written from scratch, bringing greater performance, less database queries and a core that’s easier to maintain and test. In other words; faster, stronger and eventually more stable.

However, the old APIs will still work. In fact, the backoffice of Umbraco in v6 still uses most of the old APIs. But the core team, have made some super clever engineering that means that even though you call the old APIs, internally your calls will be re-wired to the new APIs. So not only does this mean that we can use the existing back office to test if that really works, your old code will work, just much faster yet you don’t need to do anything. We’d like to call it respecting our legacy.

With v6.1 that follows - knowing that the new APIs worked as we expected -  we’ll be changing the back office to use the new APIs directly and mark the old API methods as obsolete (though you can still use them without build errors). You could call that paving the way for the future of a - code wise - more stable and elegant core codebase.

V7 for dummies

Umbraco v6 and v7 living bon mariage style

While v6 is all about internals and code, ensuring a beautiful inner soul, v7 is all about beauty on the surface. With v7 we’ll be introducing the new UX - the artist also known as project “Belle”. It’ll use the exact same core as v6 - in fact the two versions will be maintained in parallel for quite a while.

Again, we’ll be respecting legacy as people are not forced to jump on a whole new look and feel until it make sense to them (and before it’s completely stable). And again we’ll be paving the way for the future as we can focus on the richer possibilities that modern browsers brings, leaving older browser support at the doorstep of v6 (if your organisation for some reason are forced to stay on an old version of Internet Explorer, you can continue to use Umbraco through the side-by-side maintained v6).

Umbraco as a Service aka “Concorde”

While our baby is still to receive its final name, the final thing in the horizon is our cloud offering of Umbraco, which is the artist formerly known as “Codename ‘Concorde’”. It’s not your usual “CMS hosted in the cloud”, instead we’ve been designing a whole new development and deployment experience with the possibilities that a cloud platform brings us.

There’ll be a lot to talk about and even more to show over the next months, but it’s worth mentioning here as we’ll be able to move existing Umbraco installations onto our new platform opening up a whole new way of developing, sharing and deploying despite you didn’t started out on the “Concorde” platform originally.

TL;DR

So 2013 will bring us three major new goodies; a whole new faster and stable API, a stunning new user friendly look‘n’feel and finally an easier and faster way to develop and deploy your fantastic Umbraco solutions. And all that in a way, that’s compatible with what you know today while giving you the chance to learn smarter ways to do Umbraco in the future.

9 comment(s) for “Respecting legacy, paving the way for the future”

  1. Gravatar ImageJeroen Breuer Says:

    I've been testing the v6 nightly builds with some of my package and most of the legacy API still works, but it does have a few breaking changes.

    1 If you don't use the .Save() method your properties aren't saved: http://issues.umbraco.org/issue/U4-1363#comment=67-4367

    2 Before and after save events work different: http://issues.umbraco.org/issue/U4-1372#comment=67-4409

    It's cool that most package will just work out of the box, but it might be important to mention that there are a few breaking changes with the legacy API.

  2. Gravatar ImageSebastiaan Janssen Says:

    @Jeroen Yes, this will of course be well documented in the release notes. This wasn't supposed to be a technical blog post. :)

  3. Gravatar ImageMorten Christensen Says:

    Jeroen, the point about SemVer was that a major version like v6 will contain breaking changes. We do our best to keep breaking changes to a minimum and respecting the legacy parts, but we also need to move forward.

    We'll write a more technical blog post detailing the breaking changes once v.6.0.0 is ready for release. So much more information will be available in the near future ;)

    - Morten

  4. Gravatar ImageRobert Says:

    Any guess when v6 is to be released?

  5. Gravatar ImageStephen Roberts Says:

    Is there any docs yet on the new api?

  6. Gravatar ImageGrant Thomas Says:

    What do you mean by the following statement?

    "we’ll be changing the back office to use the new APIs directly and mark the old API methods as deprecated (though not obsolete)"

    Obsolete methods are deprecated, the two are synonyms. In face, the standard Microsoft message for the ObsoleteAttribute goes something like: "This method has been deprecated, please use X instead'."

    Could you clarify your intentions on this and what the implications are?

  7. Gravatar ImageNiels Says:

    @Grant: Sorry, my fault. Simply that we'll mark the methods Obsolete, but not considered an error (ie. it'll give build warnings, but won't terminate the build)

  8. Gravatar ImageYoume Says:

    @Grant: Obsolete methods are deprecated, but deprecated methods are not necessarily obsolete. To deprecate something means that it will in the future be obsoleted, but methods marked as deprecated can remain in use until the time that they are obsoleted. It's basically a way of saying, "hey, you can use this now, but try not to because it will disappear at some point in the future."

  9. Gravatar ImageGrant Thomas Says:

    @Niels After interacting with Sebastiaan on Twitter we figured this out (and Sebastiaan even made a change to the source based on this!). Thanks for the clarification. Though 'Warnings as Errors' (which should be true in most cases) will mean these warnings break a build. But, this is the trade-off, and something that needs to be done, definitely.

    @Youme I respectfully disagree. Obsolete (or deprecated, pick any word that means the same!) methods will still work, of course, as they still exist, and they fire a warning, so only when 'Warnings as Errors' is configured to be true with this cause a broken build. But you're right, it's indicative of something that exists but shouldn't be used - do you know of a DeprecatedAttribute that means something different to ObsoleteAttribute? No because it's one in the same.

    If something doesn't exist then it's not marked obsolete, indeed it can't be, it doesn't exist!

Leave a comment