|
|
| (59 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 is still in a pre-alpha state, with monthly development releases. We are aiming for an ns-3.1 release in mid-June 2008.
| + | |
| − | | + | |
| − | === June 15, 2008 (ns-3.1) ===
| + | |
| − | | + | |
| − | ==== ns-3.1 overview ====
| + | |
| − | | + | |
| − | In general, ns-3 is trying to finalize the API including final revisions to the object model, to the default value system, and to higher-level topology/scenario code.
| + | |
| − | | + | |
| − | An initial strawman for the ns-3.1 release is discussed in [http://mailman.isi.edu/pipermail/ns-developers/2008-April/003993.html this thread].
| + | |
| − | | + | |
| − | '''Note:''' Different numbering (e.g., major/minor, with even numbers corresponding to "stable" and odd to "unstable") may be adopted.
| + | |
| − | | + | |
| − | ==== Items to finish for ns-3.1 ====
| + | |
| − | | + | |
| − | '''Note: This needs updated to account for some python bindings slip'''
| + | |
| − | | + | |
| − | # documentation: need work to convert tutorial to new helper API.
| + | |
| − | # socket implementation bugs:
| + | |
| − | ## udp needs a finite rx packet buffer
| + | |
| − | ## tcp needs a finite tx and rx byte buffer
| + | |
| − | ## tcp needs to implement its tx and rx buffers as lists of packet pointers, and not raw buffers to handle correctly application-level tagged packets
| + | |
| − | ## packet tagging implementation and API needs to be rewritten to track tags on a byte-basis to allow application-level tagged packets to work with tcp sockets
| + | |
| − | ## tcp sockets need to implement the "send" callback as was discussed many times, that is, it needs to invoke that callback when there is new room in the tx buffer, not when a packet is sent down the stack.
| + | |
| − | # socket API additions: need to add the API Mathieu suggested in the socket thread to allow future implementations of posix C-style sockets
| + | |
| − | # socket API changes: tom suggested to move to a SocketHelper class the raw buffer management.
| + | |
| − | # python bindings: there are a number of key issues:
| + | |
| − | ## need to verify that gustavo's proposed implementation addresses our key use-cases: a) allow users to write new C++ models and bind them to python without having to install gccxml CVS and pygccxml, b) allow users to modify and hack a released version of the ns3 c++ API and have the python binding still work without having to install gccxml CVS and pygccxml.
| + | |
| − | ## document the overall structure of the python bindings: we need to know how they work at least from a high-level perspective. basically, a 1-page a4 document about how the code is generated and how the generated works. Assuming that the reader knows the details of the python low-level binding API works is ok.
| + | |
| − | | + | |
| − | ==== Proposed schedule for ns-3.1 ====
| + | |
| − | | + | |
| − | * 22-04-2008 -> 15-05-2008: 3), 4), 2.5), 2.3), 2.4), 5). Ideally, we would be ready to merge the python binding on the 15-05-2008
| + | |
| − | * 15-05-2008: Release release-candidate-1 (stable C++ core API)
| + | |
| − | * 15-05-2008 -> 31-05-2008: 1), 2.2), 2.1), polishing of python bindings.
| + | |
| − | * 31-05-2008: release release-candidate-2
| + | |
| − | * 01-06-2008 -> 15-06-2008: bug-fix only stage, documentation review, polishing
| + | |
| − | * 15-06-2008: release final version.
| + | |
| − | | + | |
| − | === TBD (early August?) (ns-3.2) ===
| + | |
| − | | + | |
| − | == 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.
| + | |
