src/content/community/releases/35/release-fixes.html - netbeans-website-cleanup - Git at Google

 <!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>
	<!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>
	<br>
	</body>
	</html>