ns-3 releases are based on date-driven schedules: rather than target a set of features for a specific version number, we aim instead for a release date and ship whatever is ready by that date. Sometimes releases are delayed, but we aim to release three times per year (January, May, September).

An ns-3 release manager manages each release. Following the ns-3.X release, a new release manager is selected for the ns-3.X+1 release. The old ns-3.X release manager is typically responsible for any maintenance ns-3.X.Y releases. The Release Manager is allowed to veto and remove any new feature addition if it begins to cause problems and looks like it threatens the stability of the release at any time in the release process.

Each release is roughly structured as follows: large major intrusive changes that are the most destabilizing to the codebase should be merged first early on during the cycle. As we approach the release deadline, the number and the size of the changes should decrease until only high-priority bugs are fixed during the coding freeze period. Release candidates are published for final testing.