|
|
| (57 intermediate revisions by 5 users not shown) |
| Line 1: |
Line 1: |
| | {{TOC}} | | {{TOC}} |
| | | | |
| − | This page summarizes the release roadmap for ns-3. A summary of current development activities can be found [[Current Development|here]].
| + | see the [[Current_Development]] page |
| − | | + | |
| − | __FORCETOC__
| + | |
| − | | + | |
| − | == Release schedule ==
| + | |
| − | | + | |
| − | ns-3 plans regular date-driven (not feature driven) releases. ns-3 stable releases are sequentially numbered starting with minor version 1 (ns-3.1, released June 30 2008).
| + | |
| − | | + | |
| − | === ns-3.2 ===
| + | |
| − | | + | |
| − | ns-3.2 is tentatively scheduled for the very end of August. An initial strawman for the ns-3.2 release is discussed in [http://mailman.isi.edu/pipermail/ns-developers/2008-July/004457.html this thread].
| + | |
| − | | + | |
| − | Here are some planned features; more details are on our [[Current Development]] page
| + | |
| − | # Python bindings (already merged)
| + | |
| − | # Network Simulation Cradle
| + | |
| − | # initial IPv6 components
| + | |
| − | # a learning bridge
| + | |
| − | # synchronization primitives and a real-time scheduler
| + | |
| − | # update on API and implementation for Packet tags
| + | |
| − | # some IPv4 refactoring
| + | |
| − | # statistics framework
| + | |
| − | | + | |
| − | == Release process ==
| + | |
| − | | + | |
| − | 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. If a cool new feature misses that date, it is not a big deal because the next release is never too far away. Because the project is currently still under some heavy flux where a lot of APIs still change, the current interval between releases is expected to be roughly one month. We expect that interval to increase to 3 or 4 months once the core of the simulator has stabilized sufficiently.
| + | |
| − | | + | |
| − | The roadmap below is tentative. That is, the goal is to document what we would like to see in a number of releases, but, of course, since this is an Open Source project, contributors are free to work on anything they are interested in and try to merge it in earlier than stated. If we feel a specific feature targeted to a specific release just won't make it in time, we will move that feature to the next release.
| + | |
| − | | + | |
| − | Some of the items in this roadmap do not have anyone signed up to get work done on them. So, there is something you are interested in, ask on ns-developers.
| + | |
| − | | + | |
| − | Detailed steps for doing the source code release are found in the [http://code.nsnam.org/ns-3-dev/file/1e8249c58fda/doc/release_steps.txt doc/release_steps.txt] file in the ns-3-dev repository.
| + | |
| − | | + | |
| − | === Deadlines ===
| + | |
| − | | + | |
| − | There are a few deadlines and steps for incorporating code into a scheduled ns-3 release:
| + | |
| − | | + | |
| − | * '''(15 days prior)''' deadline for posting any patches or private repos that are solicited for review/comment, for possible check in to the upcoming release. These are for patches or repos that can be considered as extensions to the simulator. Post a summary to the list, allow 7 days (minimum) for comments, and if all comments and issues can be resolved in that time window, it can go into the next release; otherwise it slides until when things are resolved.
| + | |
| − | * '''(7 days prior)''' deadline for being in a "ready-to-merge" state, which means that there is agreement that comments from the previous stage have been resolved and that the change can go in. Perhaps a "last-call" announcement by the release manager on the list will help.
| + | |
| − | * '''(3 days prior)''' deadline for merging any extensions or new modules that change the API, or any miscellaneous changes by maintainers. Exceptions: critical bug fixes, doxygen and documentation, and coding style alignment nits.
| + | |
| − | | + | |
| − | Finally, it is good practice to announce among the active committers when you are doing a major merge, to avoid bad merge collisions.
| + | |
