<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
   <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
   <meta name="GENERATOR" content="Mozilla/4.79C-CCK-MCD  [en] (X11; U; SunOS 5.8 sun4u) [Netscape]">
   <title>Distribution of bug fixes for NetBeans 3.5</title>
<link rel="Stylesheet" href="../../../netbeans.css" type="text/css" title="NetBeans OpenSource Style">
</head>
<body>

<h1>
Distribution of bug fixes for NetBeans 3.5</h1>

<h3>
Contents</h3>

<ol>
<li>
<a href="#Introduction">Introduction</a></li>

<li>
<a href="#Bugfixes branch">Code Branch for Bug Fixes</a></li>

<li>
<a href="#Commit Policy">Commit Policy to "release35_fixes" Branch</a></li>

<li>
<a href="#Issuezilla Tracking">Tracking of Bug Fixes in Issuezilla</a></li>

<li>
<a href="#Tracking of available fixes">Tracking of Available Fixes</a></li>

<li>
<a href="#Distribution">Distribution of Modules Through Update Center</a></li>
</ol>

<h3>
<a NAME="Introduction"></a>Introduction</h3>
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.
<br>This problem is going to be solved by the introduction of these changes:
<ul>
<li>
Create a special branch for bug fixes</li>

<li>
Define commit rules on this branch</li>

<li>
Distribute modules built from that branch to users through update center</li>
</ul>
This approach will bring recent fixes of the latest stable distribution
to users.
<h3>
<a NAME="Bugfixes branch"></a>Code Branch for Bug Fixes</h3>
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.
<h3>
<a NAME="Commit Policy"></a>Commit Policy to "release35_fixes" Branch</h3>

<ol>
<li>
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.</li>

<li>
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.</li>

<li>
The fix must be verified by the developer in NetBeans 3.5 build.</li>

<li>
Description of the fix together with attached contextual diff should be
sent to <a href="mailto:reviewers@netbeans.org">reviewers@netbeans.org</a>.
If nobody will object within 24 hours, the commit is considered to be approved.</li>

<li>
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.</li>

<li>
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.</li>

<li>
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.</li>
</ol>
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.
<h3>
<a NAME="Issuezilla Tracking"></a>Tracking of Bug Fixes in Issuezilla</h3>
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.
<h3>
<a NAME="Tracking of available fixes"></a>Tracking of Available Fixes</h3>
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.
<h3>
<a NAME="Distribution"></a>Distribution of Modules Through Update Center</h3>
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:
<b>https://netbeans.org/updates/hotfixes/35_{$netbeans.autoupdate.version}_{$netbeans.autoupdate.regnum}.xml</b>
<br>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.
<p>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 <a href="mailto:robert.novak@sun.com">robert.novak@sun.com</a>
who will make it available through the hot fixes update center.
<br>&nbsp;
<br>&nbsp;
</body>
</html>