Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
Yet another tiny improvement to the release process
[simgrid.git] / doc / doxygen / inside_release.doc
index 40cf33b..1620515 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 "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)
-  - You also tested to build and install the content of the source
-    archive on a reasonable amount of platforms (typically, 2 or 3).
+  - 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.
 - 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
+- Release notes in the documentation
+  - The content of the future mail is part of the documentation, since
+    we won't send mails once gforge is definitly turned off.
+  - The date of the release is marked in the title
+- Tests
+  - The "make distcheck" target works (tested by jenkins)
+  - All tests pass on everything on ci + AppVeyor
+  - Tutorials and derivative projects build correctly
+    https://framagit.org/simgrid/simgrid-template-s4u/pipelines
+    https://framagit.org/simgrid/external-projects-ci/pipelines
+  - The python module builds (see below).
+  - The java jarfile builds from the github action
+
+@subsection inside_release_c_releasing Actually releasing SimGrid
+
+- Update the version number in:
+  - CMakeLists.txt (in macros SIMGRID_VERSION_*)
+  - sonar-project.properties
+  - docs/source/conf.py
+  - setup.py
+- Commit and push to both framagit and github
+- Wait for both appveyor and jenkins/osX to complete the build
+- If it's not successful, fix it and push again
+- Once it's successful everywhere: merge 'master' into 'stable' and push it to framagit
+  - You can interrupt the build on jenkins, as it was tested just before
+  - This builds the tar.gz artefact.
+
+- Download the simgrid-doc-3.X.Y (artefact of pipeline 'pages' on framagit)
+  Download the tgz file (artefact of the pipeline 'stable' on framagit)
+  Build the jar file using the github action
+- Tag the git repository v3.XX.X and push it to framagit and ghub
+- Document the tag on framagit and ghub
+  - Upload the files simgrid-3.XX.tar.gz, simgrid-3_XX.jar and simgrid-doc-3_XX.zip
+  - Add a link to the version of the ChangeLog that comes with this tag.
+    https://framagit.org/simgrid/simgrid/-/blob/v3.29/ChangeLog
+- Update the website
+  - emacs org/org-templates/level-0.org to change the release version, the tgz link and the jar link.
+  - jed .gitlab-ci.yml
+    - Change the link to the simgrid-doc-3_XX.zip file
+    - Only keep 2 old versions so that people don't find older ones in google
+    - Change the link to latest
+  - git commit -a && git push # Check that the pipeline goes well on framagit
+
+- Rebuild and upload the python package
+  - rm -rf dist/ ; python3 setup.py sdist # Build a source distrib
+  - test that the built distrib recompiles:
+    rm -rf /tmp/pysimgrid && mkdir /tmp/pysimgrid && cp dist/simgrid-*.tar.gz /tmp/pysimgrid
+    (cd /tmp/pysimgrid && tar xfz simgrid*.tar.gz && cd simgrid-*/ && python3 setup.py build)
+  - Upload it to pypi (WARNING: you cannot modify uploaded files, ever)
+    twine upload dist/simgrid-*.tar.gz
+
+@subsection inside_release_c_publishing Publishing the release if it's a stable one (3.XX not 3.XX.Y)
 
-\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
-- 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
 - Announce the release
- - Mail the simgrid-user mailing list
+ - Mail the https://sympa.inria.fr/sympa/review/simgrid-community 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'. 
+    - Hall of Fame in the mail
+      git shortlog -se v3.29..
+    - 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
+- Push the stable branch to github to rebuild and push the stable Docker images
+  - It downloads the latest tag on framagit
+  - Doing the same manually: cd tools/docker && make stable && make tuto-s4u tuto-smpi
+    (tuto-mc is not based on simgrid/stable but rebuilds from the git)
+  - Once the new images are built, trigger a rebuild of the simgrid-template-{s4u,smpi} repositories on framagit
+- Add the new simgrid/stable image to the .gitlab-ci.yml of:
+  - https://framagit.org/simgrid/simgrid-template-s4u/
+  - https://framagit.org/simgrid/simgrid-template-smpi/
+
+@subsection inside_release_c_postrelease Post-release cleanups
+
+- Create the template for the next release in ChangeLog and NEWS files
+  Release Target date: https://en.wikipedia.org/wiki/Equinox
+- Bump release number to 3.X.1 in CMakeLists.txt sonar-project.properties docs/source/conf.py setup.py
+- Deal with deprecations:
+  - jed include/xbt/base.h: Introduce the next XBT_ATTRIB_DEPRECATED_v??? macro
+  - 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.
+- Regenerate the unstable docker with this new version
+
+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 where Y is even: dot release of 3.X, prerelease of 3.(X+1)
+    - 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.Y where Y is odd: git current status between two releases
+    - No expectations on such versions
+  - Example
+    - 3.22.4: unannounced/loosely documented stable release
+    - 3.22.5: git status somewhere between the release of 3.22.4 and the next one
+    - 3.23: Documented and announced stable release
 
-\verbatim
-$ cd simgrid-ruby
-$ git reset --hard master
-$ git clean -dfx
-$ mkdir build
-$ cd build
-$ cmake ..
-$ make dist
-\endverbatim
 
 */