-/*!
+/*!
@page inside_release Releasing SimGrid
@section inside_release_c Releasing the main library
- 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 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
- All changes are documented
- The release date is indicated below the changes
- 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
+ - 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 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
-@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.
+- 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_postchecks Check list after releasing
+@subsection inside_release_c_publishing Publishing the release if it's a stable one (3.XX not 3.XX.Y)
-- 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)
-- Update the link scm.gforge.inria.fr:/home/groups/simgrid/htdocs/simgrid/latest
- - Create the directory of the released version and upload the doc artefact in it
- - Remove the older releases so that people don't find them in google
-- 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 files to the changelog.
-- Rebuild and resynchronize the website so that the file gets visible
- 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
+ - Mail the https://sympa.inria.fr/sympa/review/simgrid-community mailing list
- the NEWS chunk in the mail;
- - Hall of Fame in the mail@n
- git shortlog -se v3.21..
+ - 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
- 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/
+ - 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
+ - If it was done automatically at some point, make sure that it's really the latest stable,
+ as things get sometimes out of synch to the point that the github action re-build the previous release.
+ If this happens, just rerun the docker-stable action. Nothing should have been broken.
+ - 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
-- Change the release number to 3.X.90 in CMakeLists.txt and sonar-project.properties docs/source/conf.py
+- Bump release number to 3.X.1 in CMakeLists.txt sonar-project.properties docs/source/conf.py setup.py
- Deal with deprecations:
- - Introduce the XBT_ATTRIB_DEPRECATED_v??? macro for the next release.
+ - 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.
-- Update the Docker images (after pushing to the git)
- - cd tools/docker && make stable tuto-s4u push
+- 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
+
*/
