unison/doc/release_steps.txt

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 that the new bake configurations for the release work correctly
   - confirm all documents build:  './waf docs' and check outputs

Check out a clean ns-3-dev somewhere using ns-3-allinone 
   - git clone https://gitlab.com/nsnam/ns-3-allinone.git
   - cd 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 tagging release candidates.

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

We'll refer to the release number as "X" or "x" below.  

creating the distribution tarball
---------------------------------

1. Create final tarballs
    You need to work with a clean ns-3-allinone-3.x directory, assuming that
    ns-3-dev is ready for inclusion as is, just with a modified VERSION file
   - git clone https://gitlab.com/nsnam/ns-3-allinone.git
   - cd ns-3-allinone
   - ./download.py
   - cd ns-3-dev
   - edit VERSION to the proper '3.x' string  (but do not commit this change)
   - cd ../
   - ./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
----------------------------

Note:  The below scripts currently presume mercurial and must be updated

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 Jekyll-based main website
---------------------------------------

1. create a new ns-3.x page which should be visible from
https://www.nsnam.org/releases/ns-3-x.

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. Create a blog entry to announce release 

patch for upgrade
-----------------
Prepare a patch for upgrading from ns-3.(x-1) to ns-3.x, and upload to
the releases directory on the web server.

ns-3 wiki edits
---------------

1. Create ns-3.(X+1) wiki page if not done already.

2. edit front page and Roadmap

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 GitLab.com and 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/