| <!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 "releaseXY_base" 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 "releaseXY" off the tag "releaseXY_base".</li> |
| |
| <li>In releaseXY change the version id from development to "X.Y |
| beta", 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 "beta", "RC1", |
| "RC2", "" (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> |