Skip to Content

When SAP released SAP HANA SP07, it was clear that there was a change to the delivery strategy. For me, it’s only become clear in the last few days how deep this change is in the HANA developer culture at SAP. I get a lot of questions on this so thought it was worth calling out.

It’s definitely worth noting the big change is that customers want HANA to have mission-critical stability. This has been reflected in product strategy.

How is HANA developed?


The main thing to note is that SAP HANA is developed with an agile methodology. This means that releases are created when they are required, not when they are mandated. This causes customers some confusion because they are used to SAP providing clear roadmaps on when releases will be made. However, I believe this is a good thing, because HANA moves much more quickly as a result. The agile trade-off is some uncertainty, for increased productivity.


In any case, there is no sense complaining about this because this is the strategy SAP chose for HANA. I think it serves the product well, but customers do need to get used to it.

How and when are HANA Support Package Stacks (major revisions) delivered?

Despite the agile methodology, SAP looks to release two major releases of HANA per annum. In the past these have been delivered in the timeline of the major conferences – SAPPHIRE, in May/June, and TechEd, in October/November. This aligns with SAP’s past communication strategy and whilst SAP’s marketing strategy has focussed to being much more year-round, I think the major release will continue this way.

So in 2014, we expect HANA 1.0 SP08 in May/June and SP09 in October/November, with some flex based upon delivery schedule.

What sort of changes are delivered in HANA Support Package Stacks?

Support packs are where features are added. For instance in SP7 we got a spatial engine, and major improvements to all sorts of tooling and core database platform functions. You can expect a SPS to contain substantial new functionality, and potentially changes to core functionality and deprecation of old features.

In short, you need to carefully regression test when you upgrade to a new HANA SPS, and read the accompanying documentation.

How and when are HANA Revisions (minor revisions) delivered?

In the past, we got revisions every 2 weeks. This allowed a lot of innovation, but it had the negative that releases were not as stable as we would like. SAP have changed their regression test strategy to be much more comprehensive, and this means they will be released on demand, according to bug fixes only. It took 10 weeks to get from Revision 70, to 71, for example. I hear Revision 72 will come soon after 71, as there are some bugs in 71 that need addressing.

What sort of changes are delivered in HANA Revisions?


In the past, we used to get innovations delivered in HANA Revisions, and this is no longer the case. Customer feedback is that stability needed to be put ahead of new functionality.

What you will get in HANA Revisions is improvements to performance, stability and security. In HANA Revision 71 there are a total of 55 changes. The word “fixed” appears 44 times, “error” 39 times, “crash” 24 times, “performance” 8 times. You get the idea.

What are Maintenance Revisions (critical patches)?

Maintenance revisions allow you to continue to get critical fixes for the last HANA SPS after a new SPS has been released. These will continue for 3 months after the new SPS has been released. It allows customers with mission-critical environments to plan the update to the new SPS whilst still getting fixes for critical problems.

It is great for customers who have a project track and a support track – you can keep updating the support track with the maintenance revisions whilst you upgrade the project track to the latest SPS.

What sort of changes are delivered in Maintenance Revisions?


Maintenance Revisions are limited to critical bugs and security holes. For instance, according to SAP Note 1935871, Revision 69.01, 69.02 and 69.03 contain 19, 18 and 9 critical fixes, respectively.

Final Words

The HANA release strategy can be confusing and I hope this clears it up. Thanks to Michael Eacrett for making some clarifications. It is clear that SAP is making a big push to make HANA bulletproof, and we are seeing signs of this strategy working.

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Martin Maruskin

    John,

    can you comment also on term weekstone? I notice this term in some of SAP Notes related to HANA.

    Is it build generated on weekly basis on which developer of HANA do regression tests?

    If so, that this is only SAP internal thing and probably makes no interest at all for customers.

    Thanks,

    m./

    (0) 
    1. John Appleby Post author

      Hi,

      Yes, I can share what the weekstone releases are. Each calendar week, there is an internal build of HANA built. This week is Weekstone 2014.08. Many developers use the weekstone build to test the latest features.

      As I understand it, the weekstone doesn’t have a full regression test against it because it is designed to be a developer build. Weekstones are (almost) never used in customers.

      The only interest to customers is to understand how fast HANA moves for internal builds.

      John

      (0) 

Leave a Reply