How We Do Releases at NetBeans

NetBeans Release Process

• Releases should happen approximately every six months - that is, two releases each year. This is the goal.
• At all times we need to be looking toward the next release and the one following it. Not all releases are equal. We may plan huge changes in one release and a lot of stabilization work in the next one. That's not to say that we would tolerate a buggy release - but as NetBeans evolves, it is predictable that there will be occasional significant rewrites of certain functionality. Other releases may only involve incremental improvements. Given the modularity of NetBeans this also applies at the module level.
• Although the general schedule is one release every six months, exact dates must be set for each release.
• The release schedule consists of
  1. Feature freeze - a time after which no new functionality will be introduced. Only code changes due to bug fixes will be allowed to be checked into CVS.
     • At this time a side branch is created in CVS for adding bug fixes and documentation changes. The naming convention for this branch in CVS is releaseNN where NN is the pending release version.
     • After feature freeze, user interface changes should be minimal. Any pending UI changes should be communicated in advance and only be done in the name of fixing bugs.
     • During the stabilization phase the binaries are marked as NB X.Y beta. Daily builds is made available for download and all users are invited to test the software. Developers are expected to promptly respond to bug reports. Bug reports are of course preferably filed in the bug database, but the developers should also monitor the nbusers mailing list and reply to users' feedbacks posted there.
     • During the stabilization phase the README and release notes are written. The first drafts of these two critical documents should rather be made earlier than later.
  2. Stabilization phase - During which any bugs that are outstanding are fixed.
  3. Release candidate 1 - The first release candidate. If no serious issues are found the last release candidate automatically becomes the final release. There must be at least one week between the last release candidate and the final release.
     • After the first release candidate is made all code changes must be negotiated in advance by posting requests on the mailing list.
  4. Release candidate 2 - The second release candidate
  5. Final release - The final, public release of a new version of NetBeans

The Release Manager

• The release manager is the person who tracks the whole release process for one release.
• The main responsibility of the release manager is keeping all involved people informed about the state of the release. The most important things are dates and bug counts. The release manager is expected to keep a list of things which need to be done and to ensure that someone is taking care of them.
• The release manager is expected to raise unresolved issues on mailing lists and drive the discussions to closure.
• The release manager does not have the authority to decide on his/her own what will or will not be done.

The Release Manager's Responsibilities

• Keep people informed about the dates: feature freeze, release candidates, final release.
• The release manager is the one who creates the new branch in CVS. There must be several notices in advance. After the branch is created, a note must be sent out letting people know exactly when the branch was created and for what. Don't forget to include the timezone, preferably use GMT/UTC time.

  The critical act is creating the new branch. The release manager should send out the steps he or she plans in advance so that people know what to expect and have a chance to comment. The following are the minimum steps:

  1. Put a tag "releaseXY_base" on CVS trunk
  2. Check out the tagged sources
  3. Build, if the build fails cancel everything, fix the problems and go back to step 1, e.g., retag
  4. Make a branch "releaseXY" off the tag "releaseXY_base".
  5. In releaseXY change the version id from development to "X.Y beta", this includes some strings in Bundle.properties and the splash screen
  6. Go through manifest files for all modules in the CVS trunk and increment their OpenIDE-Module-Specification-Version. Also increment Specification-Version for openide.
  7. Reset the build number of X.Y to 1, make the first build of X.Y beta, push the bits on netbeans, post an announcement

• As the release moves forward, the version will need to be re-labelled "beta", "RC1", "RC2", "" (nothing = final release). Find out in advance the place in the code you need to change (grep is your friend).
• When in doubt rather say more than say less, be as much detailed as possible, don't rely on unsaid rules, don't rely on common sense (there is no such thing :-)
• After the final release the release manager should hold a post-mortem discussion on what has been done well and what poorly and propose changes for the future.