blob: 6112bf7f585c6b08cf0221558d96386cfa35832e [file] [log] [blame]
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<HTML>
<HEAD>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>How We Do Releases at NetBeans</title>
<META NAME="description" CONTENT="The NetBeans Release Process">
<META NAME="NAV_LINK" content="Release Process">
<META NAME="NAV_PRIORITY" content="4">
<link rel="stylesheet" type="text/css" HREF="../../netbeans.css">
</HEAD>
<BODY>
<h1>How We Do Releases at NetBeans</h1><br>
<!--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-->
This document describes how new versions of the NetBeans IDE are released.
<h2>NetBeans Release Process</h2>
<ul>
<li>Releases should happen approximately every six months - that is, two releases each year.
This is the goal.
<li>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.
<li>Although the general schedule is one release every six months,
exact dates must be set for each release.
<li>The release schedule consists of
<OL><LI><B>Feature freeze</B> - a time after which no new functionality
will be introduced. Only code changes due to bug fixes will be allowed to
be pushed into the Mercurial repository for the release.
<UL><LI>At this time a branched Mercurial repository is created for
adding bug fixes and documentation changes. The naming convention for this branch
is releaseNN where NN is the pending release version.</LI>
<LI>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.</LI>
<li>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.</LI>
<li>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.</LI>
</UL></LI>
<LI><B>Stabilization phase</B> - During which any bugs that are outstanding are fixed.</LI>
<LI><B>Release candidate 1</B> - 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.
<UL>
<li>After the first release candidate is made all code changes must be
negotiated in advance by posting requests on the nbdev@netbeans.org mailing list.</LI>
</UL></LI>
<LI><B>Release candidate 2</B> - The second release candidate</LI>
<LI><B>Final release</B> - The final, public release of a new version of NetBeans</LI>
</OL>
</ul>
<h2>The Release Manager</h2>
<ul>
<li>The release manager is the person who tracks the whole release process
for one release.
<li>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.
<li>The release manager is expected to raise unresolved issues on mailing
lists and drive the discussions to closure.
<li>The release manager does not have the authority to decide on his/her
own what will or will not be done.
</ul>
<h2>The Release Manager's Responsibilities</h2>
<ul>
<li>Keep people informed about the dates: feature freeze, release
candidates, final release.
<li>The release manager is the one who creates the new Mercurial branch.
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.
<P>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:
<p>
<ol>
<li>Put a tag &quot;releaseXY_base&quot; on Mercurial trunk</LI>
<li>Check out the tagged sources</LI>
<li>Build, if the build fails cancel everything, fix the problems and
go back to step 1, e.g., retag</LI>
<li>Make a branch &quot;releaseXY&quot; off the tag &quot;releaseXY_base&quot;.</li>
<li>In releaseXY change the version id from development to &quot;X.Y
beta&quot;, this includes some strings in Bundle.properties and the
splash screen</LI>
<li>Go through manifest files for all modules in the trunk and
increment their OpenIDE-Module-Specification-Version. Also
increment Specification-Version for openide.</LI>
<li>Reset the build number of X.Y to 1, make the first build of X.Y
beta, push the bits on netbeans.org, post an announcement</li>
</ol>
<p>
<li>As the release moves forward, the version will need to be re-labelled &quot;beta&quot;, &quot;RC1&quot;,
&quot;RC2&quot;, &quot;&quot; (nothing = final release). Find out in advance the place
in the code you need to change (grep is your friend).</li>
<li>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 :-)</li>
<li>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.</li>
</ul>
<!--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-->
</body>
</html>