Blogs about Jazz

Blogs > Jazz Team Blog >

Upcoming CLM milestone builds

In a blog post published earlier this month, Scott Rich and John Kellerman wrote about our plans for upcoming fix packs for CLM 2011 (Rational Team Concert, Rational Quality Manager, and Rational Requirements Composer 3.0.1) and our plans for CLM 2012.

In this post I’ll let you know how those plans will be realized in the early release builds we’ll publish here on jazz.net.

CLM 2011 Maintenance Milestones

Last month we published Rational Requirements Composer 3.0.1.1 M1, the first milestone for the first CLM 2011 fix pack. We don’t usually publish milestones for fix packs as they typically contain only defect fixes. However, as you’ll see from the set of 3.0.1.1 plan items, there are in fact some new requirements management and quality management improvements. You’ll shortly see 3.0.1.1 M3 which will contain builds for both Rational Requirements Composer as well as Rational Quality Manager. There will be no 3.0.1.1 milestones of Rational Team Concert, and after we publish RRC and RQM 3.0.1.1 M3 you won’t see any further 3.0.1.1 milestones until we publish the GA build.

CLM 2012 Milestones

If you take a look at the jazz.net downloads page you’ll see that last week we published the M1 builds for our CLM 2012 release of Rational Team Concert, Rational Quality Manager, and Rational Requirements Composer. This is the first milestone in the release that we’re working towards for 2012. Following our conventions, we needed a release number to start making the milestones available, but the current release number is somewhat arbitrary at this stage and subject to change. If you check out the “New & Noteworthy” pages for each of the products, you’ll see that even at this early stage there are new things to try out.

As we move forward with CLM 2012, we plan to publish only odd-numbered milestones. This may seem like a new thing but in fact we’ve done this before with previous releases. For example when we worked on RTC 2.0, the iterations were 4 weeks long and we published every 8 weeks. The difference was that we called the iterations M1D1, M1, M2D1, M2 and so forth with D1 referring to a deployment to our self-hosting servers without publishing the build we deployed. In 3.0.1, we published and upgraded every 3 weeks but the pace was hard to maintain for both our development teams and consumers of our builds. For CLM 2012, the iterations are 3 weeks long, but since we’re only publishing odd-numbered milestones, we’ll only publish every six weeks. You can expect to see M1, M3, M5, and M7 and then we’ll hit our RC0 (Beta) which is after both our M8 feature-freeze and our polish pass. From that point on we plan to publish each and every release candidate (e.g. RC1, RC2, etc.) and these will appear more rapidly as the length of the iterations gets shorter.

Making Upgrades Easier

One of the improvements we’ve made in making builds available is the Upgrading page. This page has been used previously but usually only for releases. When we published milestones we usually included upgrading information in the Release Notes. We plan to include the Upgrading page for all our milestones and in each we case we will provide guidance around two upgrade paths:

  • The previous builds that you can upgrade from in order to adopt the milestone
  • The future builds that you can expect to upgrade to after you’ve upgraded to that milestone

We hope this will help make upgrading clearer. Additionally we’ve been working on improving the upgrade experience with new scripts to make the upgrading faster and more robust. You’ll see some of that work in 3.0.1.1 M3 and eventually also in the 2012 stream.

Adrian Cho
Development Manager, Collaborative Lifecycle Management