Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
update our releasing process
[simgrid.git] / doc / doxygen / inside_release.doc
index 40cf33b..4874363 100644 (file)
 /*! 
-\page inside_release Releasing SimGrid
+@page inside_release Releasing SimGrid
 
-\section inside_release_c Releasing the main library
+@section inside_release_c Releasing the main library
 
-\subsection inside_release_c_preconditions Before releasing
+@subsection inside_release_c_preconditions Before releasing
 
 Please apply the following checklist before releasing.
 
 - Sources
-  - The version number is correctly marked in CMakeList.txt, in macros
-    SIMGRID_VERSION_MAJOR and friends. Please also update the
-    comments right before these macros so that we keep a track of the
-    version numbers that were used.
+  - The external patches (Debian, etc) are integrated.
+    The COPYING file is aligned with Debian's copyright file, and the
+    dates of SimGrid chunks are accurate.
+  - The version number is correctly marked in 
+    - CMakeLists.txt (in macros SIMGRID_VERSION_*)
+    - sonar-project.properties
+    - docs/source/conf.py
   - The "make distcheck" target works (testing that every files needed
     to build and install are included in the archive)
 - Tests
   - All tests pass on a reasonable amount of platforms (typically,
-    everything on cdash)
+    everything on ci + travis/macOS + AppVeyor)
   - You also tested to build and install the content of the source
     archive on a reasonable amount of platforms (typically, 2 or 3).
 - ChangeLog file
-  - Every changes are documented
+  - All changes are documented
   - The release date is indicated below the changes
-  - The release is marked as stable above the changes
+  - The release is marked as stable above the changes (remove the UNRELEASED marker)
   - The release dub name matches the one given in NEWS file
 - NEWS
   - The most notable changes of the version are documented
   - The release date is indicated right below the version name
   - The release dub name matches the one given in ChangeLog file
 
-\subsection inside_release_c_source Building the source archive
-
-First, clean up your git repository. Some files are included through
-globbing, you must ensure that your tree contains no cruft. You can
-either checkout a new tree or remove anything from your current tree:
-\verbatim
-$ cd simgrid
-$ git reset --hard master # warning, it will kill your uncommited changes
-$ git clean -dfx          # warning, it will kill your uncommited changes
-\endverbatim
-
-You can then build the archive. This gives you your archive in the
-build dir, named 'SimGrid-${inside_release_version}.tar.gz'.
-
-\verbatim
-$ mkdir build
-$ cd build
-$ cmake ..
-$ make dist
-\endverbatim
-
-\subsection inside_release_c_win32 Binary distribution under Win32
-
-You have to install nsis tool first. Download it 
-<a href="http://nsis.sourceforge.net/Download">here</a>.
-
-Then be sure having wget.exe in your path to get the online documentation. You can download it 
-<a href="http://users.ugent.be/~bpuype/wget/">here</a>.
-
-You can finally make the win installer.
-\verbatim
-$ cd simgrid
-$ mkdir build
-$ cd build
-$ cmake ..
-$ make nsis
-\endverbatim
-
-\subsection inside_release_c_postchecks Check list after releasing
-
-- Tag the git repository (don't forget to push the tags to the main
-  repo)
-- Push the archive files on gforge
+@subsection inside_release_c_source Building the source archive
+
+This should be done from a clean git repository because some files are
+included through globbing. The best is to use a clean checkout:
+@verbatim
+cd /tmp
+git clone --depth=1 ~/Code/simgrid
+cd simgrid
+cmake . && make dist
+@endverbatim
+
+If you prefer, you can clean your repository the hard way:
+@verbatim
+git reset --hard master # remove all uncommited changes to the files tracked by git
+git clean -dfx          # delete all files and directories that are not tracked by git
+cmake . && make dist
+@endverbatim
+
+@subsection inside_release_c_jarfile Building the binary jarfile
+
+Get the jarfiles for several OSes on the CI slaves. Use Save under to
+give a separate name to each of them.
+
+- macOS, FreeBSD: on Jenkins
+- Windows: on AppVeyor
+- Linux: it is safer to rebuild them in a chroot (to avoid
+  boost-context and all other optional dependencies):
+  
+@verbatim
+mkdir /tmp/build-amd64
+cp SimGrid-3.*.tar.gz /tmp/build-amd64
+sudo debootstrap --arch amd64 --variant=buildd testing /tmp/build-amd64 http://deb.debian.org/debian/
+sudo chroot /tmp/build-amd64
+echo "proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0" >> /tmp/fstab
+mount proc /proc -t proc
+apt-get install -y cmake default-jdk libboost-dev python3 doxygen
+cd tmp
+tar xfz ../SimGrid*tar.gz && cd SimGrid-*
+cmake . -Denable_documentation=ON -Denable_java=ON
+make -j4 && LC_ALL=C ctest -R java
+@endverbatim
+
+Once all jarfiles are in a separate directory, run the following to
+merge them:
+@verbatim
+mkdir content ; cd content
+
+for j in  ../simgrid-linux64.jar ../simgrid*.jar ; do unzip -n $j ; done
+# The content of all jar should be the same, but I prefer using the Linux64 version by default
+#  => unpack it first, and unpack the others with -n (never overwrite)
+
+test -e doc/javadoc || echo "YOU ARE MISSING THE DOC"
+
+du -sh .                                  # 273M here. Let's strip (Darwin is already good)
+strip NATIVE/*/*/*.so                     # Gets BSD and Linux versions, down to 116M
+x86_64-linux-gnu-strip NATIVE/*/*/lib*dll # Gets Windows, down to 22M
+
+rm ../simgrid-3_*.jar
+zip -r ../simgrid-3_XX.jar *              # Produced ../simgrid-3_XX.jar is 7.7M
+@endverbatim
+
+To upload the file on gforge, you need to go to Files/Admin then clic
+on the Settings icon near to the "Add a version" button, and then on
+the settings icon of the release you want to change.
+
+@subsection inside_release_c_postchecks Check list after releasing
+
+- Tag the git repository (don't forget to push the tags to the main repo)
+- Push the archive files (tar.gz and jar) on gforge
+- Post a news on gforge (before updating the website)
+- Document the tag on https://github.com/simgrid/simgrid/releases and
+  on https://framagit.org/simgrid/simgrid/tags
+  - Upload the files SimGrid-3.XX.tar.gz, simgrid-3_XX.jar and
+    SimGrid-doc-3_XX.zip (that is the artefact of the pages job on framagit) files to the changelog.
+- Update the .gitlab-ci.yml on the website
+  - Download the simgrid-doc from framagit and unpack it in position
+  - Only keep 2 versions so that people don't find older ones in google
 - Rebuild and resynchronize the website so that the file gets visible
-  from our download page (see @ref inside_doxygen_website).
-- Update the link ff-scm-v4-prod:/home/groups/simgrid/htdocs/simgrid/latest
+  from our download page.@n
+  - Edit org/org-templates/level-0.org to change the release version, the tgz link and the jar link.
+  - emacs org/site/index.org and C-c C-c the first source block to refresh the news; fake the date in the result.
+  - emacs org/site/download.org and C-c C-c the first source block to refresh the download.
+  - emacs org/site/documentation.org and edit the version links.
+  - make -C org all sync
+  - jed .gitlab-ci.yml
+    - Change the link to the SimGrid-doc-3_XX.zip file
+    - Change the version number
+    - Change the link to latest
+  - git commit -a && git push
 - Announce the release
  - Mail the simgrid-user mailing list
     - the NEWS chunk in the mail;
-    - the ChangeLog chunk as attachment
- - Also mail some other lists (G5K users), with only the NEWS chunk
-   and the link to the download section
-
-\section inside_release_bindings Releasing the bindings
-
-Please apply the above checklists before and after releasing the bindings.
-
-Then, clean your git repository and build the archive. It will give
-you an archive file in the build dir:
-'SimGrid-Ruby-${inside_release_version}.tar.gz'. 
-
-\verbatim
-$ cd simgrid-ruby
-$ git reset --hard master
-$ git clean -dfx
-$ mkdir build
-$ cd build
-$ cmake ..
-$ make dist
-\endverbatim
+    - Hall of Fame in the mail@n
+      git shortlog -se v3.21..
+    - Link to the ChangeLog on framagit (the version of that tag)
+ - Also mail some other lists (G5K users)
+- Release the debian package
+  - rm -f ../simgrid_3.*+dfsg.orig.tar.xz
+  - uscan # download the new version
+  - gbp import-orig ../simgrid_3.*+dfsg.orig.tar.xz
+  - dch -i "New upstream release" # + copy the NEWS into debian/changelog
+  - git mv debian/libsimgrid3.XX.install debian/libsimgrid3.XY.install
+  - edit debian/control: s/simgrid3.XX/simgrid3.XY/ 
+- Update the simgrid/package.py for spack: https://gitlab.inria.fr/solverstack/spack-repo
+- Create the template for the next release in ChangeLog and NEWS files
+  Release Target date: https://en.wikipedia.org/wiki/Equinox
+- Change the release number to 3.X.90 in CMakeLists.txt and sonar-project.properties docs/source/conf.py
+- Deal with deprecations:
+  - Introduce the XBT_ATTRIB_DEPRECATED_v??? macro for the next release.
+  - Kill the one for the current release and remove all code that were
+    mandated by the deprecated functions (both in source and headers).
+  - Do the possible cleanups now that these features are gone.
+- Update the Docker images (after pushing to the git)
+  - cd tools/docker && make stable tuto-s4u push
+
+Release numbering semantic: 
+  - 3.X is a named release. 
+    - We have 4 named releases per year (for each equinox and solstice)
+    - The ChangeLog and NEWS are complete and informative
+    - All tests pass on all ci systems (or the workarounds are documented)
+    - We provide and store a source .tar.gz and a full jarfile on framagit
+    - Deprecated symbols remain usable for at least 3 named releases (~1 year)
+    - These releases are announced to the users
+  - 3.X.Y is a dot release of 3.X
+    - We provide and store a source .tar.gz and a full jarfile on framagit
+    - These releases are NOT announced publicly, nor really documented. 
+      The idea is to have something close to a rolling release.
+    - External projects can depend on dot releases to loosen their
+      release process from ours, when 4 release a year is not enough 
+  - 3.X.90 is a git version, a preversion of 3.(X+1) (3.22.90 = pre-3.23)
+    - No expectations on such versions
+    
+Doing a dot release:
+  - Update the version number in:
+      - CMakeLists.txt (in macros SIMGRID_VERSION_*)
+      - sonar-project.properties
+      - docs/source/conf.py
+  - Commit and push to both framagit and github
+  - Wait for both appveyor and jenkins/highsierra to complete the build
+  - If it's not successful, fix it and push again
+  - Once it's successful:
+    - tag the release v3_X_Y and push the tag
+    - Merge 'master' into 'releases' and push it to framagit
+    - Do not merge into 'releases' before appveyor and jenkins are done,
+      or your jarfile will not contain the code you expect for win and
+      mac.
 
 */