Discussions

News: Java Future: Moving from Tigers to Mustangs and Dolphins

  1. Now that Tiger has shipped, some people are looking to the future. Mark Reinhold of Sun has discussed how the release model has been changed. There won't be any more maintenance releases. Update releases will ship every 2-3 months instead. The reasons for the change are to ship releases on time, and to help release adoption.

    Mark Reinhold on the new release schedule
    Whew! I can just about hear the collective sigh of relief from everyone, both inside and outside of Sun, who contributed to this amazing product. We hope you enjoy working with it. As I've said before, I think Tiger is the highest-quality JDK that we've ever built -- and I've been helping to build these things since JDK 1.1.

    This seems an appropriate time to look forward, and in particular at some changes that we're making to the J2SE release model.

    The current model has three kinds of releases:

    • Feature releases are the big ones (1.3, 1.4, 1.5 5.0), with tons of bug fixes and lots of new features. These have generally been about 24-36 months apart.
    • Maintenance releases, the so-called "dot-dot" releases (1.4.1, 1.4.2, etc.), have lots of bug fixes but no new API features. Lately these have been about 8-10 months apart.
    • Update releases, the so-called "underscore" releases (1.4.2_01, 1.5.0_01 5.0 update 1), which contain a very small number of bug fixes (typically around 100) carefully chosen to meet urgent customer needs. Sun has shipped these about every 3-4 months.
    Going forward we're going to simplify this model and increase the rate at which we ship releases. In particular:

    • Feature releases will ship every 18-24 months. This will allow the platform to evolve more rapidly so as to better meet the needs of the developer community and compete with .NET.
    • There won't be any more maintenance releases. Starting with Tiger (5.0) there won't be any more releases the size of 1.4.1 and 1.4.2, i.e., with 1500-2000 bug fixes. There still might be a release called "5.1", but it will just be a special update release.
    • Update releases will ship every 2-3 months. This will make it possible for critical bug fixes to be delivered to customers in a more timely manner.
    Changing the release model is not something we've done lightly; this is the result of several months of investigation and many conversations with partners and developers in the community. A couple additional expected benefits of these changes are:

    • Releases will more likely ship on time. Within the J2SE engineering organization we've long wrestled with the difficult choice of making the current maintenance release as perfect as possible versus working on great new features for the next big feature release. This conflict has been the proximate cause of many schedule slips over the years. The new release model finally resolves this fundamental tension: J2SE engineers will, by default, always be working on the next feature release. There will be times when they're asked to fix a critical bug in an update release, and even rarer times when some nontrivial work (e.g., to improve performance) will be done in an update release, but these will be the exceptions rather than the rule.
    • Release adoption will improve. The existing medium-sized maintenance releases have long been a big adoption barrier. Due to the level of change in these releases many users have only been confident enough to adopt them after requalifying all of their applications -- in other words, by treating them much like feature releases in terms of testing. Most users are confident enough in the update releases to just "drop them in" without doing a lot of testing; now they'll be able to do so for a longer time in between feature releases.
    These are not easy changes to make. We're still in the middle of figuring out a bunch of the details, so reality over the next couple of years might not exactly match what I've described above. Overall, however, we think that the improved focus and increased agility of the new release model will bring big benefits to the platform and to the Java community.
    Read more in Tigers and Mustangs and Dolphins, Oh My!

    Threaded Messages (4)

  2. iterative builds[ Go to top ]

    i think it's great to have improved builds in a short time basis.
    It will help the quick adoption of Java 5

    many ppl don't want to use the first final release until the first set of bugfixes has been published.
  3. iterative builds[ Go to top ]

    many ppl don't want to use the first final release until the first set of bugfixes has been published.
    So your solution is to force people to move? It feels like microsoft.
  4. iterative builds[ Go to top ]

    I think this is a great idea. The maintenance releases quite often break things because Sun gets bullied into fixing a bug for Vendor A that hoses Vendor B, Vendor C, and Vendor D. Also, it makes life difficult for people to certify (since you may test on 1.4.2_02, however by the time your product is released, 1.4.2_05 is out and 1.4.2_05 breaks something with your application).

    Also, having shorter cycles will hopefully mitigate things like it taking 3 years to add support for the context-menu key on Windows keyboards and such. It's disturbing how long it takes for some good ideas to finally filter into Java. Shorter release cycles will help this, and reduce the potential incompatibilities between maintenance releases.

    Of course I may be wrong, but here's how I see it.

    -- Rob
    http://www.robsite.org
  5. I'm confused[ Go to top ]

    The existing medium-sized maintenance releases have long been a big adoption barrier. Due to the level of change in these releases many users have only been confident enough to adopt them after requalifying all of their applications -- in other words, by treating them much like feature releases in terms of testing. Most users are confident enough in the update releases to just "drop them in" without doing a lot of testing; now they'll be able to do so for a longer time in between feature releases.
    I read this like this:
  6. <ui>Folks used to regression test their software against Maintenance releases, but not necessarily Updates
  7. This regression testing slowed down adoption of Maintenance releases
  8. Since now they're only doing Updates, folks shouldn't have to do regressions at all now, and just trust the Update.
  9. This tells me that either they're not going to have as severe of changes in their Updates as they did in their Maintenance releases (thereby, ideally, not warranting a regression test), or they're going to make those changes anyway, but just call them Updates.

    If they're not going make the changes that would previously have qualified as a Maintenance release, then how does this advance the platform more quickly? It seem they're basically holding those back for the next major release. But I guess they're going to release major upgrades more often, so its less of an issue.

    Is that how others read this?