This release marks the first release in a new quarterly release rhythm for CLM.
Some of you might be thinking “Does this mean I need to upgrade every quarter?!” The answer is “No, we don’t expect you to do that.” We understand that upgrades involve significant planning and testing, and most of you will plan only a couple of upgrades per year. Our goal with quarterly releases is to ensure that, when you do decide to upgrade, the latest features and fixes are available. We also know that we need to earn your confidence to encourage adoption of the quarterly releases, so we’ve managed the content of this first quarterly release very carefully. CLM 4.0.2 is essentially a fix release.
Across the products, we’ve included over 60 APAR fixes and over 550 additional defect fixes in 4.0.2. We’ve back-ported many bugs that we discovered in our internal testing and development of future features, but we’ve also managed those back-ports carefully to make sure we don’t regress. We’ve put a focus on upgrading by adding upgrade tests to our automated deployment pipeline. Our goal is to make quarterly releases as easy to install as fix packs. In fact, the upgrade instructions for the 4.0.2 release are identical to our last fix pack.
When we talk to you about CLM quality, performance is a topic that comes up frequently. Therefore, we put a focus on careful performance fixes in 4.0.2, and delivered several performance fixes across the products. Once you’ve registered at jazz.net, you can see the details on our Performance 4.0.2 Dashboard tab. Also, you can see that we’re already working on some more ambitious performance items for our next quarterly release.
In addition to the fixes in this release, we’ve upgraded a few software dependencies. We officially support Firefox 17 now, so we fixed a few surprises that we ran into when testing CLM with that version. We also upgraded the bundled and supported versions of Tomcat and Java 6 to pick up critical fixes. See the system requirements for details.
While we put this fix release together, we also worked on improving our ability to deliver features which are truly “done, done” on a quarterly rhythm. We’ve adopted a checklist that guides the feature team to consider all the aspects of delivering a feature into the CLM release. For each feature, the team is responsible for reviewing the applicability of all the items on the feature checklist, and determining which are required. We build a wide variety of features, and not all of them have to check all the checkboxes. The point is that the team should consider them all and make a conscious decision. We’re finding that the team’s initial assumptions usually overlook one or two important items. Check out a typical item under development.
As teams assess their features, they create the necessary tasks to ensure the checklist completion, and our normal release planning can track progress towards our Done Criteria. This may look like a lot of additional work, but in fact it’s just an honest assessment of the work we need to do beyond writing the code and testing. In the past, we always had to address these requirements, but they were less visible, and often subject to pushing into the end-game of a release, causing a tremendous crunch to really get to done.
The performance improvements and our feature checklist are just a couple of improvements we’re making in our ways to deliver better quality features more frequently. We will continue to focus on improving our process to better enable us to support your needs as we continue our quarterly release rhythm for CLM. As I mentioned earlier, 4.0.2 is the start of this rhythm and we hope that you see the improvements in this release as well as our subsequent quarterly releases.
Scott Rich, Distinguished Engineer
IBM Developer Experience and Rational CLM Cloud Lead Architect
Loading...
Thanks a lot for the summary and hard work from the team.
Just curious about the release number convention. CLM 4 FixPack 1 was 4.0.0.1. The modification release 1 was 4.0.1.0. Now we have 4.0.2.0, which really sounds a modification level but it is certainly not. I came to this summary article after I clicked a few places to find “what is new” in 4.0.1 and certainly did not find anything new (feature).
Should the release number be something like 4.0.1.1? And 4.0.3 would be really 4.0.2?
Thanks and regards
Frank
Hi Scott,
So we possibly expect 4.0.3 around June (during 2013 Innovation Conf:-))?
Awesome, FF17! Love the new release rhythm idea. 60 APARS fixes – can’t wait! Woohoo! Great job!
Hi Frank, if you followed us closely the last few months, you could see we were asking ourselves the same questions. In the end, we decided that this was a significant enough release to call it 4.0.2. Our hope is to make each of the 4.0.x quarterly releases interesting and easy enough to adopt that they become our primary releases. We will still produce 4.0.x.x releases with critical fixes, but hopefully they become less interesting over time. To your second question, the quarterly rhythm would say that is a reasonable expectation. ;-) Thanks for your feedback.
Thanks, Scott.
Is there a quick performance report on 4.0.2 compared with 4.0.0/4.0.1?
Thanks and regards
No new performance report for 4.0.2, we just ran regression tests to make sure we kept performance on par. There were a couple new performance articles published recently for RRC and DOORS Next Generation:
https://jazz.net/library/article/1232
https://jazz.net/library/article/1216
Scott,
Plan Item 230373 has some great content with regard to the done – done criteria. Is it possible to get a copy of the template for use with customers? Is there code that generates the text in the checklist notes or is that held within a work item template ?
Would be good to explore how the content can be shared with customers some time.
Mark Roberts
Rational UK
Hey Mark, thanks for your interest in the done checklist. Let me check with the development team. I know it hasn’t yet been packaged up in a reusable form, but it sounds like a good idea. The checklist text is low-tech, it’s copy/pasted.
Hi Scott,
we are using CLM 3.0.1. we see that there is change in Email notification format. It is better than what we used to receive previously. Is it part of this fix?
Hi Scott,
Thanks for the insight into your road-map considerations. I want to promote the idea (highlighted in your post above) that IBM’s upgrade testing be strengthened, especially with regard to the behavior of artifact histories and formal review information. Work Item 83769 (NullPointerException encountered when fetching manual script history [s]) is a great example of why I am promoting this concept. We were looking to upgrade to RQM 4.0.2 but given the presence of issue 83769 in 4.0.2, we are probably going to wait until the release of RQM 4.0.3.
Being that we are working in the medical devices space, we need to have absolute certainty that the basics of our tools are working without incident. Having access to artifact histories falls squarely into the area of “basics” for us given the need to be able to mine history data during audits.