Catch Your Next Release! (An Overview of the V.R.M.F Versioning System
March 15, 2018
Most of Rocket’s MultiValue (MV) products have long followed IBM’s “V.R.M.F” maintenance stream numbering system where each number change represents the significance and/or the amount of change within a planned software release. You may have noticed that with the launch of UniVerse 11.3.1 back in October 2016, both DBTools 4.3.0 and U2 Common Clients 5.1.0 have switched from a “Month Year” release identifier to the V.R.M.F numbering system.
Understanding V.R.M.F. For Better Testing and Certification Cycle Planning
As more and more products across Rocket are adopting this same V.R.M.F. numbering system for release levels, it’s important to understand the implications of each number change so that you can better plan your testing and certification cycles. Obviously, larger releases will require more testing duration, so by reading a roadmap with V.R.M.F in mind, you can make better forecasts for dedicating the necessary time and resources when planning your upgrade schedules.
In an agile world, enterprise customers demand faster speed-to-market and more continuous delivery of smaller releases to solve very targeted mission-critical problems ASAP. However, many of these same enterprise customers tell us that they can only digest a new release of their MV Application Platform every 1-3 years, as it takes significant time to validate their application on that release and to roll it out to their vertical market. These larger releases need to deliver maximum value due to their slower adoption cycles. Like taking delivery of a car, you wouldn’t want each piece of a new car delivered to you separately across many weeks or months. However, if you are only in need of a car battery to keep your existing car running, the quickest delivery option is often the best. So, there is value in both the larger releases for launching new products or major new features as well as the smaller releases for quickly solving specific problems. Therefore, it’s important to point out that each release type listed above has its own set of pros and cons.
To better understand these differences let’s think about each V.R.M.F. release as a different delivery vehicle. In the shipping logistics world, business customers place orders (large and small) and wait for their valuable merchandise to arrive. Each delivery vehicle depicted below has a different cargo capacity, a different speed to market, and thus a different tolerance for plan changes. Larger, slow-moving delivery vehicles tend to contain the greatest amount of value and are the most difficult (and expensive) to change course or deviate from schedule. The number of customers who depend on larger delivery vehicles is much higher and these releases tend to travel a much further distance (making it take longer) to reach their target markets. The longer release schedule of a Version change is typically due to the scale of development changes in the software and the extensive amount of testing, documentation, and cross-training that must be performed prior to releasing to the market. These types of releases need to be carefully planned out, tested, and documented to meet the highest quality standards to stand up to the rigors of any customers’ application and production environment.
Versions (V.R.M.F)
A “Version” change is the slowest delivery vehicle to market, yet it contains the most value… much like a cargo ship traveling from one country’s port to another, carrying 150,000 tons of cargo. In the software world, a Version change may include a redesigned architecture and/or major new features and functionality that impact the end users’ business in some positive way. The contents within a Version change can be extensive, so they are usually grouped together into several large categories or “themes,” where they provide more synergistic value by being delivered and marketed together. In other words, there are major content changes that only make sense to be shipped together and not be broken up and delivered separately, as the solution would be incomplete. Since Version changes take significant investment to create, they also face the most internal scrutiny from a business perspective. These are often the “long bets” a company makes, where the ROI may be several years out. QA cycles are longer to test all the various content and ensure no regressions were introduced. Betas are mandatory for these types of releases to verify the quality as much as possible before it ships to the rest of the world. Even after the Version release arrives to market, customers still take their time with these releases and often will spend several months testing their business applications with the new Version before they adopt it into their production systems. An example of an upcoming MV product release that represents a Version change is UniVerse 12.1, releasing later in 2018. This release includes a major re-architecture to support faster performance and higher data integrity with a Recoverable File System (RFS). The last time we unveiled a Version change for UniVerse was UniVerse 11.1 back in 2011 when we introduced (HA/DR) U2 Replication, External Database Access (EDA), and the XAdmin GUI tool as part of DBTools.
Releases (V.R.M.F)
After a Version change in the V.R.M.F model comes the Release change. I like to think of Releases as long freight trains traveling from one end of a country to another… slowly meandering across a variety of terrain types… carrying 5,000 tons of payload of fixes and enhancements for various customers to get what they need from the train’s contents. Like a Version change, Releases have a known velocity and a fixed delivery schedule that are often tied to various marketing activities and enabling customer projects. Releases often contain significant enhancements, documentation, and marketing activity that all contribute to giving the customer new capabilities to work into their software solution. They also are an opportune time to change platform support or deprecate outdated features, if it makes sense with where the market is headed. Releases tend to include new OS Platform certifications (while dropping older OS Platforms) so that Rocket can support the lifecycle of that Release level over several years to ensure best-in-class security and performance. Since they carry so many fixes and enhancements, Releases are very difficult to slow down or stop once they have momentum. Since the freight train has a long journey and a tight schedule to keep, it won’t turn around or wait if you miss the opportunity to have your content included. You’ll simply have to wait until the next one scheduled to comes along because the train has already left the station. Some may refer to this slow and large delivery cycle as “Waterfall” but it actually can be the strategy for what is known as “Scaled Agile Framework” for Lean Enterprises, where the Agile Release Train is on a fixed schedule and the business owners identify strategic themes that they target for large releases to address. A great example of a recent MV product Release is UniVerse 11.3.1 (October 2016) which added native bi-directional Python support (among many other new features) and deprecated all 32-bit OS platforms, making 64-bit the gold standard.
Mods (V.R.M.F)
The “M” or Mod-level release can travel much faster in the most direct path, and has fewer contents to deliver. There is never a feature or platform deprecation at a Mod-level release and the expectation is for customers to quickly and easily test the release and move it into production. The speed is valued over the amount of cargo that can be carried, much like paying a premium for “2nd day air” delivery. Since there is a much more frequent flight schedule, with many options for rescheduling, Mod releases give customers more options to catch if you miss the first flight out of town. Much like 747 cargo planes limited to carrying only 150 tons of cargo, Mod-level releases generally target high severity bugs and may contain minor (and often un-related) enhancements. These smaller releases tend to target fewer customers and strategic themes. They’re seen as “maintenance” releases that help keep customers satisfied on their current Version and Release. Mod-level releases are much more flexible on delivery date, but have an upper limit on how much value they can deliver at a time. A recent example of an MV product Mod-level release is that of D3 10.2.2 (Windows only) released in May 2017, and that of wIntegrate 6.4.2 released in December 2017.
Fix Packs (V.R.M.F)
Finally, the fourth digit change in the V.R.M.F numbering system is “F” or Fix Pack release. Fix Packs are the fastest and smallest release types, often only delivered to one customer with a lightly tested “fragile” delivery package. Much like a typical courier delivery truck, only limited to 1-2 tons of cargo, Fix Packs are very limited in scope by design and have a very limited audience. They are often hidden from sight as a “controlled release” or “hotfix”… much like a package hidden behind a bush or under a mat on your front porch. These types of releases are often early deliverables that still require more testing before they can be released as Generally Available (GA) for the rest of the market. They value speed over everything else and are therefore only tested on the target customers’ OS platform, environment, and feature set in use. These types of urgent releases can typically be turned around in a matter of days or weeks, and are the most agile delivery vehicle in terms of responding to changes in plans and delivering incremental value. When browsing Rocket Business Connect (RBC) for an MV product Fix Pack, you may not see many releases with a fourth digit because most of these are hidden from view and known as a “Controlled Release.” The Rocket MV support staff handles the delivery of the hotfix and gives our customers a secret V.R.M.Fxxx number to type in to access the download, since it is not fully tested for all other platforms and certified for general use. Fix Packs are designed to be a temporary solution, where once the next GA release becomes available (be it a Mod-level or a Release-level), the customer is advised to upgrade to the fully certified release that contains their fix.
It’s important to know that any release type (V.R.M.F) can be either GA for all customers to download and upgrade, or a “Controlled Release” where only limited customer(s) can see and download a particular release that was designed for them.
I hope you enjoyed learning about the different V.R.M.F delivery vehicles and their pros and cons. Rocket MV is always working to streamline our processes and make our releases as efficient as possible. There will always be a need for each type of release, and hopefully this information makes it easier to develop your testing and certification plans when planning to adopt new releases. I’m curious to know your thoughts and questions below on these topics. Please post a comment or question below!
