NetBeans 6.0 Patching process

!!DRAFT!! Description of how we can deliver bug fixes to NetBeans 6.0 after its release using Update Center as patches.

Patch will be a set of modules with fixes delivered at once to NetBeans 6.0 users. Patched modules will be grouped into the kit. Kit defacto defines the patch, e.g. Patch 1, Patch 2,.... Newer patches are dependent on previous patches they are cumulative. This is mainly to reduce the mess like: Module A updated in Patch 1, then in Patch 3, while Module B depends on Module A and it was updated in Patch 2. With cummulative patches we can assume just version of Module B from Patch 2.

  1. Patches will be done on a dedicated branch created after 6.0 release.
  2. Daily builds from this branch will be done. This build will produce just nbms for UC.
  3. There will be defined date for patch release. Everybody knows the date and can act accordingly
  4. Branch will be marked in High Resistance two weeks before the patch release. It allows testing and stabilization.
  5. Patch will appear on Beta UC - allows wider testing
  6. Testing will be performed on NB 6.0 FCS as sanity testing effort two weeks prior release.
  7. If some module does not pass then it has 2 days for fix or it is removed. 2 days for fix might seem too short, but this will help us to keep on the schedule and not retest, retest and retest the patches.
  8. When tested, patch will appear on NetBeans UC.
  9. Patch availability is announced using news system of NB.org. Includes list of patched modules & list of bugs fixed


  1. Branch & tools setup - Build Engineering
  2. Fixing on a branch - Sustaining and Development
  3. Patch build preparation and verification - Sustaining
  4. Testing the patch - Quality and Users?
  5. Patch announcement - Sustaining.

To be defined

  1. How to patch and keep NetBeans distributions the same? We cannot deliver e.g. SOA modules to people who have just Java SE distro.
  2. Fixes selection for patch? What development wants, or what is pointed by users.
  3. Include also feature additions? Eg. Extended Ruby support delivered via patch


Jirka Rechtacek

Concept of grouping patches into kit modules should work in current implementation of Autoupdate but there are several constraints of this concept:

  • Service Pack Kit is a new module and will be presented in New Plugins tab to users
  • If a kit is applied then all its dependencies must solved. It means if an user download&install Java SE IDE (w/o J2EE, UML, ...) and later wants to apply a patch (which contains updates of UML), installation of the patch will cause installation of UML as well. In general: if a patch contained updates over full IDE, its install would install rest of full IDE.

Ways to solve these problems:

  • Implement more support for Service Packs (e.g. special marker for patch modules, specific handling patch-modules)
  • Needs requirement for this functionality w/ scenarios for all possible cases
  • Needs middle-sized changes in Autoupdate code
  • IMHO too late for NB6.0 FCS
  • Deliver Service Packs in as same granularity as FCS distro.
  • Make use of Updates Notification icon in IDE status line for exclusively updates.
  • Add new one type of Update Center dedicated for Important/Security updates only
  • Notify updates only from that Update Center
  • Needs a only minor-size change in Autoupdate code. No risky

Jesse Glick

Why do we need "patches" at all? Just deliver module updates with the fix. Place them on a hotfix update server which we configure to be on by default. No changes needed to Auto Update whatsoever. No kits, no special support needed to enforce correct order of installation. AU will already offer updates using a separate UI from new modules. All Linux distributions do it this way, successfully.

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo