Lesson from JDK Release Milestones

So far, (most of us) only know how to use a software product (or framework, development kit). We download, install, use, and happy (hopefully for most of the case). In case of opensource, we also only know that opensource is the program that it's code can be seen, modified, and shared with anyone. Actually there are other aspects of open source that are also interesting, important, and may benefits us who are mainly working in IT fields (programmers, project managers, or IT entrepreneurs). This aspect is the software development process that occurs so that all these products can be in our hands today. Of course if we willing to dig and study it.

In this post I'll write about project's milestones that happen in Java Development Kit (JDK) release, especially after the proposal release train to "one feature release every six months" rather than the current two-year schedule already took effect.

Project's Milestones

In project management, a schedule is a listing of a project's milestones, activities, and deliverables, usually with intended start and finish dates. Those items are often estimated by other information included in the project schedule of resource allocation, budget, task duration, and linkages of dependencies and scheduled events.

A milestone is a marker in a project that signifies a change or stage in development. Milestones act as marker to define (planned) important achievement through the course of your project, helping ensure you stay on track. The milestones is a way of knowing how the project is advancing, should represent a clear sequence of events that incrementally build up until your project is complete.

As example, let see JDK 8 Milestones:

JDK 8 Milestones

The JDK 8 development schedule was divided into a sequence of milestone cycles, most six to eight weeks in length, with builds occuring roughly once each week. There were no formal beta or early-access releases. Major features and other potentially-destabilizing changes were targeted for integration early in a specific milestone.

Here is the milestone schedule:

Milestone definitions

The early development milestones (M1–M6) were date-driven; they came and went regardless of the state of the release. Most later milestones are condition-driven; the team intended to reach the goal of the milestone by the given date, but if not then the team declared the milestone at a later date and adjusted any following milestones as necessary. Here are definitions of the later milestones, in the order in which they occur:

• Feature Complete — All features have been implemented and integrated into the master forest, together with unit tests.
• Developer Preview — A reasonably stable build suitable for broad testing by the developer community is published. This build will include all planned features unless otherwise stated.
• All Tests Run — All planned tests have been run, at least once, on all supported platforms.
• Rampdown — Phases in which increasing levels of scrutiny are applied to incoming changes. In phase 1, only P1-P3 bugs can be fixed. In phase 2 only showstopper bugs can be fixed.
• API/Interface Freeze — After this point APIs and other interfaces, including those defined in component JSRs, can be changed only in order to fix showstopper bugs.
• Zero Bug Bounce (ZBB) — The bug backlog is completely addressed. No open bug with a fix targeted to the release is older than 24 hours, and other bugs have been deferred to a future release.
• Final Release Candidate — The date by which the final release candidate must be declared and submitted for testing. One or more release candidates will be declared after the planned ZBB date; if another is necessary after this milestone then the GA date will be at risk.
• General Availability — Final release, ready for production use.

JDK 9 Milestones

The milestone definitions for JDK 9 were the same as those for JDK 8, with the addition of:

• Feature Extension Complete — The date by which JEPs and small enhancements that have been granted extensions via the FC extension-request process must be integrated into the master forest.
• Initial Release Candidate — The date on which the first release candidate is built and submitted for testing.

Start from Java 9, Java move to 6-monthly release cadence. The team stabilized the release in an increasingly-rigorous sequence of phases, listed here for the record:

• Rampdown Phase One — only P1-P3 bugs can be fixed.
• Rampdown Phase Two — only showstopper bugs can be fixed.
• Release-Candidate Phase — in JDK 9, JDK 10, and JDK 11 release consists of Initial Release Candidate and Final Release Candidate.

What I Observe:

Although the "train" move faster:

• Java (JDK) contributors come from all over the world, from different organization,s working in different locations, different timezone. Together and dedicated, they build our lovely JDK in such quality.
• Since Java 9, JDK is released every six months, ie every March and September.
• Since the first release (Java 9), there has never been a late release.

So if we are working in same company, same building, same floor (only different cubicle), having coffee (and beer) together, using "agile" in our projects but the project keep demanding overtime but after that the quality is still so-so, with so many open bugs... really something wrong here.

References:

• JDK 8 Project
• JDK 9 Project