This repository was archived by the owner on Jan 5, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 7
/
Copy pathrelease_steps.txt
221 lines (171 loc) · 8.05 KB
/
release_steps.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
Steps in doing an ns-3 release
We typically post release candidates for testing at the following URL:
https://www.nsnam.org/release/ns-allinone-3.X.rcX.tar.bz2
This overview covers the following release stages:
1) new feature additions and bug fixing
2) preparing release candidates for testing
3) making the actual release
4) maintaining the release
1) new feature additions and bug fixing
---------------------------------------
During the software development phase, it is important for the release
manager to try to maintain the following files with updated information:
- AUTHORS
- RELEASE_NOTES
- CHANGES.html
otherwise, this becomes painful to edit (and things are forgotten)
when the release is imminent.
2) preparing release candidates for testing
-------------------------------------------
This step presumes that you have a reasonably solid ns-3-dev that you
and/or the buildbots have been testing
- building static, optimized, and debug versions
- try Python visualizer (not tested by buildbots)
-- ./waf --pyrun src/flow-monitor/examples/wifi-olsr-flowmon.py --vis
- ensure that tests pass (./test.py -g) and make sure that the buildbots
are reporting blue based on the tip of the repository
- revise and check in AUTHORS, RELEASE_NOTES, and CHANGES.html
- required versions for related libraries (nsc, netanim, pybindgen)
are correct
- confirm that Doxygen builds cleanly (./waf doxygen),
- confirm all documents build: './waf docs' and check outputs
Check out a clean ns-3-dev somewhere using ns-3-allinone
- hg clone http://code.nsnam.org/ns-3-allinone
- ./download.py
- cd ns-3-dev
- edit VERSION such as "ns-3.14.rc1" (DO NOT commit this change to ns-3-dev)
- cd ..
- ./dist.py
This should yield a compressed tarfile, such as: ns-allinone-3.14.rc1.tar.bz2
Test this, and when satisfied, upload it to
www.nsnam.org:/var/www/html/releases/ (with apache:apache file ownership)
Announce it to ns-developers as:
https://www.nsnam.org/release/ns-allinone-3.14.rc1.tar.bz2
Iterate the above as needed during the release testing phase.
Note, in the past we have added mercurial tags to ns-3-dev to denote
release candidates, but lately we have not been bothering with this.
If you would like to tag a release candidate, follow these steps
-- hg tag "ns-3.X.rcX" (for the appropriate version numbers)
-- hg push ssh://code@code.nsnam.org/repos/ns-3-dev
3) making the release
---------------------
Follow similar steps for creating the release candidate tarballs, except
we will work off of a release repository.
At this point, you are ready for final packaging and repository/site work
tagging ns-3-dev and creating ns-3.X repositories
-------------------------------------------------
We'll refer to the release number as "X" or "x" below. The steps here
involve tagging ns-3-dev, copying over ns-3-dev to ns-3.X on code.nsnam.org,
cloning it locally, making changes from "3-dev" to "3.X" in various places,
and checking in those changes to the new ns-3.X repository.
1. once you are happy with the most recent release candidate tarball and
do not plan to further touch ns-3-dev, tag ns-3-dev
- cd into ns-3-dev
-- hg tag "ns-3.x"
-- hg push ssh://code@code.nsnam.org//home/code/repos/ns-3-dev
2. copy the tagged ns-3-dev and place it on the repository
- ssh code.nsnam.org; sudo bash; su code;
-- cp -r /home/code/repos/ns-3-dev /home/code/repos/ns-3.x
-- cd /home/code/repos/ns-3.x/.hg and edit the hgrc appropriately:
[paths]
default = /home/code/repos/ns-3.x
[web]
description = ns-3.x release
name = ns-3.x
contact = <ns-developers@isi.edu>
3. check out a clean version of the new release (ns-3.x)
to a scratch directory on your local machine
- hg clone http://code.nsnam.org/ns-3.x
5. Update the VERSION for this new release, in the ns-3.x directory (i.e.
NOT in ns-3-dev)
- change the string 3-dev in the VERSION file to the real version
(e.g. 3.14) This must agree with the version name you chose in the clone.
- change the version and release string for the documentation in
doc/manual/source, doc/tutorial/source, doc/tutorial-pt-br/source,
and doc/models/source conf.py files
This should hopefully be updated in the future to simply pull from the
VERSION file.
- hg commit -m "update VERSION to ns-3.x"
- hg push ssh://code@code.nsnam.org//home/code/repos/ns-3.x
creating the distribution tarball
---------------------------------
1. Create final tarballs
You need to work with a clean ns-3-allinone-3.x directory
- hg clone http://code.nsnam.org/ns-3-allinone
- cd ns-3-allinone
- ./download.py -n ns-3.x
- ./dist.py (notice we did not build here)
- this will create an ns-allinone-3.x.tar.bz2 tarball
- sanity check this tarball just to make sure everything went ok
2. upload "ns-allinone-3.x.tar.bz2" to the /var/www/html/releases/ directory on
the www.nsnam.org server
- scp ns-allinone-3.x.tar.bz2 www.nsnam.org:~
- ssh www.nsnam.org
- sudo cp ns-allinone-3.x.tar.bz2 /var/www/html/releases
- cd !$
3. give it 644 file permissions, and user/group = apache if it is not already
- sudo chown apache:apache ns-allinone-3.x.tar.bz2
- sudo chmod 644 ns-allinone-3.x.tar.bz2
4. if this is a final release (not RC)
- delete RC releases from /var/www/html/releases
preparing the documentation
----------------------------
1. If final release, build release documentation
- sudo bash; su nsnam; cd /home/nsnam/bin
./update-docs -r http://code.nsnam.org/ns-3.x -R
2. Check if these new files are available on the website
3. In ns-3-dev, edit the tutorial "Getting Started" page to
update the release version numbers.
preparing the Wordpress-based main website
------------------------------------------
1. create a new ns-3.x page which should be visible from
http://www.nsnam.org/ns-3.x
- New Features
- Download
- Bugs Fixed
- Documentation
2. Repoint http://www.nsnam.org/releases/latest to the new page
Repoint http://www.nsnam.org/documentation/latest to the new page
Repoint /var/www/html/doxygen-release to the new release doxygen.
3. Update the Older Releases page to create an entry for the previous
release (there are two such pages, one under Releases and one under
Documentation)
4. The main page http://www.nsnam.org should point to
ns-3.x in the "Download" and "Documentation" boxes
5. The releases page http://www.nsnam.org must be updated (including
source tarball link)
6. Create a blog entry to announce release
ns-3 wiki edits
---------------
1. Create ns-3.(X+1) wiki page if not done already.
2. edit front page and Roadmap
Bugzilla
--------
1. Add a product version "ns-3.x" to the available versions.
Announcing
----------
1. Final checks
- check manual, tutorial, model, and doxygen documentation links
- download tarball from web, build and run tests for as many
targets as you can
- download release from mercurial, build and run tests for as
many targets as you can
- test and verify until you're confident the release is solid.
2. announce to ns-developers and ns-3-users, with summary of release notes
4) maintaining the release
--------------------------
First, create skeletal sections in CHANGES.html and RELEASE_NOTES to
start collecting inputs for the ns-3.(x+1) release.
The project may decide to make incremental, bug-fix releases from
time to time, with a minor version number (e.g. ns-3.7.1). To do
this, changesets may be cherry-picked from ns-3-dev and added to
ns-3.x repository. Do not move over changesets that pertain to
adding new features, but documentation fixes and bug fixes are good
changesets to make available in a minor release. The same steps
above for making a release are generally followed, although one
does not need to create a separate repository, but instead just tags
the existing ns-3-dev and ns-3.x repositories with a "ns-3.x.1" type
of tag.
Also, on the main website, make sure that "latest release" points to
the right page. See how it was handled for ns-3.12 (which made
a minor release): https://www.nsnam.org/ns-3.12/