Distribution of bug fixes for NetBeans 3.5

Contents

1. Introduction
2. Code Branch for Bug Fixes
3. Commit Policy to "release35_fixes" Branch
4. Tracking of Bug Fixes in Issuezilla
5. Tracking of Available Fixes
6. Distribution of Modules Through Update Center

Introduction

In the NetBeans 3.5 release there were left many low priority defects which could not be integrated into the release. Some of these bugs are already fixed in the development builds or are going to be fixed there. But there is no simple way for these bug fixes to be available to users.
This problem is going to be solved by the introduction of these changes:

• Create a special branch for bug fixes
• Define commit rules on this branch
• Distribute modules built from that branch to users through update center

This approach will bring recent fixes of the latest stable distribution to users.

Code Branch for Bug Fixes

A special branch is necessary where the bug fixes are provided. The branch name is "release35_fixes" and this branch is created for all modules in the standard distribution of NetBeans 3.5. The branch is created from "release35" branch at the time NetBeans 3.5 FCS was built (Jun 2 2003). When committing to that branch, following steps has to be taken in order to minimize the probability that regressions will be incorporated.

Commit Policy to "release35_fixes" Branch

1. Only fixes of defects, that does not introduce UI changes (or cause trivial UI changes that do not affect documentation) can be committed to that branch.
2. The defects should be fixed in the development build first and should pass at least one Q-build. If the defect is not present in the development build or the fix is different in development build and 3.5 build, this step can be ignored, but an extra care must be taken to the next step.
3. The fix must be verified by the developer in NetBeans 3.5 build.
4. Description of the fix together with attached contextual diff should be sent to . If nobody will object within 24 hours, the commit is considered to be approved.
5. Every bug fix should be integrated separately in an extra commit. More than one bug fix should not be integrated in one round, because this makes hard to be able to track down the changes later on.
6. The long description of the module's manifest should list the bugs that are fixed by this update (just bug numbers should be sufficient). It should reference an HTML document describing the bugs that were fixed. This can be viewed through the [More...] button.
7. To mark, that the content of "release35_fixes" branch for the given module is ready to be distributed to users, the specification version of that module should be increased. To avoid collisions with hotfixes provided for Sun One Studio it is necessary to have specification version of 6 digits. The current specification version of the module is extended with zeros and last with a non-zero number. So if the specification version of a module in NB 3.5 is 1.3.1, the specification version of the first update should be 1.3.1.0.0.1, of the second update 1.3.1.0.0.2, etc.

This policy should minimize the risk of introduction of regressions. If after all a regression will be introduced it is supposed to be found by the users soon and the responsible developer should fix it (or revert the fix that caused the regression) as soon as possible. The advantage of this process is that regressions should be caught soon, which will improve the quality of the provided fixes.

Tracking of Bug Fixes in Issuezilla

In order to be able to find which issues are provided as fixes to users, "3.5_Fixes" Target Milestone will be created in Issuezilla. If an issue, that is not resolved yet, is planned to be fixed in release35_fixes branch and distributed through the update center, this Target Milestone can be used to notify the submitter about that. If the issue is resolved, this Target Milestone means that the bugfix is already provided through the update center.

Tracking of Available Fixes

Every module should keep a list of bugs which fixes are distributed through the update center. This list should be available as an HTML document located at the module web pages and referenced from the long description of the module's manifest. The list should contain the number of the defect in Issuezilla and a short description for the user explaining what is fixed.

Distribution of Modules Through Update Center

The fixed modules will be available at a dedicated "Hot Fixes" Update Center. In order to configure the new Update Center in the IDE a small module should be created that installs the new "Hot Fixes" Update Center. The new Update Center can also be set manually for NetBeans 3.5 to point to: http://www.netbeans.org/updates/hotfixes/35_{$netbeans.autoupdate.version}_{$netbeans.autoupdate.regnum}.xml
The mechanism of how the modules will be built and uploaded to the update center is to be determined. Currently we are examining whether it will be possible to setup an automatic process for that.

Until a more convenient mechanism is created, if developers would like to make the fixes available through "Hot Fixes" Update Center, they should build their modules themselves into NBM module. This can be done by "ant nbm". The nbm module should be tested in NetBeans 3.5 build to verify that it was built correctly and sent to who will make it available through the hot fixes update center.