Introducing the future Umbraco roadmap

Friday, July 13, 2012 by Niels Hartvig

core-team-2012

The wonderful people from the 2012 Umbraco Core Retreat where it all started.

I'm excited to finally announce the roadmap for the Umbraco core for the next six months. Since the action at CodeGarden '12, we've been working hard on digesting all the input from the core mailing list, feedback from our partners and conversations with the community.

TL;DR: We'll release often and everything we work on will be transparent, so you know where and how you can contribute.

Based on feedback, we've decided to change how we release. In the past, this has been too random, leaving community and partners surprised when there was a release and by what it contained. It has caused a lot of uncertainty for professional users, as it's been hard to plan when you don't know what to expect. It has also made it difficult for the community to know where and when they can contribute.

We believe that the most healthy solution is for Umbraco to be in constant development ("perpetual beta") with a short but constant flow of release cycles. This will ensure that even major enhancements are split into smaller bits, thus helping us to keep focus. Therefore, no new features will become so large that it becomes impossible for others to contribute. At the same time, there's a demand for regular, super-stable and polished versions that you can trust. With this draft we believe we've found a solution to accommodate all scenarios without compromising!

The plan is to have minor releases every five weeks, with four weeks dedicated to development (2*two week sprints) leaving one week as a beta and bug fixing sprint.

After two minor versions, we'll work on a major version based on the previous two minor versions. This major release will consist of one two week sprint with the focus on polishing the two previous releases.

This means that every quarter will bring us two minor releases containing new features, and one major release that polishes and stabilizes the work of the minor ones.

Now that you know our intent, what you really want is to look at the roadmap and see what's planned for the future. We hope that you don't just want to read it and then wait for the next release to drop, but will also want to contribute towards making it happen.

So without further ado - go to the brand new roadmap section on Our Umbraco.

Thank you to everyone involved in making this roadmap real - it has been a massive team effort. The future is incredibly bright and fun for all of us.

18 comment(s) for “Introducing the future Umbraco roadmap”

  1. Gravatar ImageJohn Says:

    So some major final releases will be unpolished and a bit ropey and some will be the same thing but working properly? How will we know which is a proper version and which has been rushed out ahead of time?

    If a version does not have the proper polishing on it then please mark it as a BETA and not a final release. (Bear in mind not all your customers are geeks wanting the latest stuff.)

    Gut feeling after reading this is that the release cycle pendulum has gone full swing in the opposite direction of version 5 whereas perhaps there's a happy medium in the middle? Releasing betas often is fine, releasing low quality final versions is absolutely not.

    I hope you lot have read this: http://www.webmonkey.com/2012/07/firefox-developer-everybody-hates-firefox-updates/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+wired%2Findex+%28Wired%3A+Top+Stories%29

    A "new public API" might be a good thing, but we already have a whole load of differing APIs for doing the exact same thing. We have two nodes, Inode, document, dynamiccontext, cmsnode, content and so on. If you are going to create yet another way of doing exactly the same thing, please can we get rid of some of the obsolete versions? Or maybe obsolete all the current assemblies and put the new stuff into new ones.

    Now which of the 3 million variants of Node in which random namespace am I going to use today?

    Sorry, don't want to be completely negative - I like the sound of the new things that have been announced, but am just a bit concerned that this is a knee-jerk reaction to the v5 disaster.

  2. Gravatar ImageDaniel Says:

    I wonder about your definition of major release:
    "This means that every quarter will bring us two minor releases containing new features, and one major release that polishes and stabilizes the work of the minor ones."

    Isn't this rather the definition of a maintenance release, supposing what you call minor releases are not in fact betas?

    Naming convention besides I like the idea of this release pattern.

  3. Gravatar ImageMorten Bock Says:

    Very nice to see the roadmap, and I like the concept of the release cycles. However, I agree with others, that the naming of the releases is a bit "funky". A developer who has not visited the roadmap is not able to tell the difference between 4.10.0 (minor) and 4.11.0 (stable), and thus might get surprised that the 4.10.0 has some rough edges?

    Would it not be easier to communicate this by changing names as such:

    4.9.0 => 4.9.0 alpha
    4.10.0 => 4.9.0 beta
    4.11.0 => 4.9.0 (RC for option to include bugfixes in final 4.9.0)
    And from then on, it would be 4.9.1 for service/bugfix releases.

    I think that is closer to what people would expect looking at the roadmap?

    I realize that the "alpha/beta" tag might mean that people will not be deploying it, and reporting bugs at that stage, but more importantly, it means that people will not be deploying it to their production environments, without knowing the risks.

  4. Gravatar ImageRobert Foster Says:

    What's the best way to propose an issue to be resolved in a particular Release? Or do we just have to hope issues raised are gotten around to/not needed any more as releases are put out?

  5. Gravatar Imagesun Says:

    One season one major stable version is the main idea.
    That's nice.

  6. Gravatar ImagePinal Bhatt [PBDesk.com] Says:

    Wow really gr8 plan. Hope it works out as schedule.
    Regarding MVC integration, will it be MVC 3 or MVC 4 ?
    Also what about .Net Framework version upgrade to 4.5?

  7. Gravatar ImagePinal Bhatt [PBDesk.com] Says:

    What's the best way to report an issue or propose a feature request? Should it be on codeplex or issues.umbraco.org ?

  8. Gravatar ImageMorten Christensen Says:

    I'd like to address the comments so far, but I'd firstly like to point out that this is our first public draft of the road map, which is open for discussion until August, which is also noted on the 'Road map'-page (link in blog post). We have already changed how we version releases once after getting some valuable feedback from the community before going public with the above. We believe this is the way to go, but we'll listen to comments and/or concerns about the version numbers and releases.

    I realize the following might be a bit misleading "After two minor versions, we'll work on a major version based on the previous two minor versions. This major release will consist of one two week sprint with the focus on polishing the two previous releases", so I'll try to explain.

    Each cycle has 3 releases, so in the first cycle we'll have 4.9.0, 4.10.0 and 4.11.0. Second cycle will have 6.0.0, 6.1.0 and 6.2.0. A third cycle, which is not yet planned, would have 7.0.0, 7.1.0 and 7.2.0.
    Because of the history with version 5 we'll have an odd jump from 4 to 6 and the minor versions of 4 might be a bit confusing, but once we're up and running we hope and think this will make a lot more sense.

    The first two releases in a cycle will introduce new features like MVC support, ui updates, new public api etc. Each of these two releases are developed over a five week period - 2 sprints and one week beta/test period before release.
    The last release in a cycle will be the polished and stable release, which is what agencies would typically use for building new sites. We choose to call it a polished release because we'll have a sprint dedicated to fixing issues that might have come up during the usages of the two previous releases. We want to get all of those small and annoying issues out of the way, the issues which would have otherwise collected dust on Codeplex.
    So if you want the latest and greatest you can use x.0.0 or x.1.0, if you want the latest stable and polished version you would use the x.2.0 release.

  9. Gravatar ImageMorten Christensen Says:

    @Morten Bock, I don't agree with using Alpha, Beta, RC for a single version number, because that is not what we intend to release. Within a cycle we'll have 3 releases with different themes that will all be usable. But if you prefer to use the polished and stable release then go for the x.2.0 release.

    @Robert Foster, If you have an issue you should report it on Codeplex (at least for the time being - we hope to migrate bug report to issues.umbraco.org during August). Prior to each release we'll have regular Sprint planing and we'll look at reported bugs to see if any of them should be included in a release. If a bug is not fixed for a x.0.0 or x.1.0 release then there is a good chance we'll fix it for the x.2.0 release, which is intended to improve stability.
    If you have found a bug and fixed it then we are more then happy to accept a pull request.

    @Pinal Bhatt, It will most likely be MVC3 and .NET 4.0. There are currently no plans to upgrade the project to .NET 4.5.

  10. Gravatar Imagefavo Says:

    It would be nice if the roadmap worked on IE 8.

  11. Gravatar ImageAsbjørn Says:

    This roadmap sure looks amazing. If you can pull this off in the time frame given, I must say that scrapping v5 was indeed the right decision after all. I am looking forward to these improvements.

  12. Gravatar ImageJuan Carlos Ruiz Pacheco Says:

    Great, I like this perpetual beta scheme.
    BUT
    Be carefull with version naming conventions, the number or version name must be totally CLEAR. if anyone wants the latest stable version , this must be very easy to find.

    I strongly recomend stablish a clear way to access beta, rc and production versions even for absolutely newbie umbraco users.

  13. Gravatar ImageJohn Says:

    Got to agree with Morten Bock about the naming - having some obscure part of the version number indicate that a release is polished is not going to be clear to anyone. You do realise you have commercial customers using umbraco don't you?

    The more I think about this idea the more worried I am. For me, one of the constant frustrations in v4 is that there are a huge number of bugs and the API is all over the place because it's existed for so long and be changed by so many different people with their own ideas- presumably the latter point is the reason why v5 was started.

    The last thing Umbraco needs is lots of hastily thrown together updates. Particularly if you're going to give the developers the ready made excuse of "this isn't the polished version so just bung in any old stuff and we'll patch it later".

    I don't want any new features unless they are going to be done properly. In my mind Umbraco v4 has suffered long-term because too many times something new and shiny has been thrust into it without the proper time being invested in making it polished.

    Also is it really sensible to give dates to the exact day for each phase? No offence but your estimating skills in the past have left a little to be desired.

    apologies if this comes across like a rant - I just don't want to see the quality of Umbraco suffer because of an over-eagerness to put new things in. Do less, but do it right - please.

  14. Gravatar ImageNiels Hartvig Says:

    A short reply as I'm on vacation.

    We're not fools and we've done our homework ;-)

    The minor releases won't be *unpolished*. The only difference is that the quarterly releases will be more polished than previous releases ever been.

    For us dates - and frequent ones - are the most important and we will deliver. The amount of work on the individual releases are kept tight and focused. Make sure to look at the roadmap and notice the plans on consolidating APIs (while keeping backwards compatibility) for instance.

    But more important; In the end we could promise gold and rainbows today and it wouldn't make a difference. What will make a difference is that we'll put your worries to shame in a few months.

    And we will.

  15. Gravatar ImageJohn Says:

    Thanks for the comments, Neils - appreciate that you've taken time off from your holiday to respond!

    The roadmap does look incredibly ambitious, but there are a lot of good things on there that I am really looking forward to. Providing the quality is there!

    I just hope that the dates won't force your hand to release something before it's ready. Otherwise we'll end up with yet more code marked obsolete hanging around.

    This worries me a little: "For us dates - and frequent ones - are the most important and we will deliver." In my mind this translates to "quantity over quality" which is not good for anyone.

    Having regular date-focused beta releases makes sense, but for a stable release I would hope that this would be reserved purely for something that has been tested and works.

    The reason I am worried is that we constantly find new bugs in Umbraco all the time and would hope that this isn't going to be an infestation of new ones!

    I will keep the faith and look forward to seeing what you deliver! Apologies for seeming overly negative.

  16. Gravatar ImageJohn Sheppard Says:

    Hello. If one needs to read documentation or it has to be explained to learn what the version numbers means....I think there's a problem...

    Even here it had to be clarified? I'm quiet regularly wrong about many things :), but to me that's an indicator something is wrong...

  17. Gravatar ImageConnie DeCinko Says:

    I see no mention of when version 4.x.x will be end-of-lifed. How much longer can we expect patches and upgrades to be released for those of us perfectly stable on version 4 with no need for features in version 6?

  18. Gravatar ImageNie Says:

    @Connie: v4 will continue to get security patches for long, but no new features will be added so expect the number of updates to be limited in the future.

Leave a comment