+ - Hall of Fame in the mail
+ 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
+- 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.
+- Update the Docker images (after pushing to the git)
+ - cd tools/docker && make stable tuto-s4u tuto-smpi push
+ - Update the simgrid-template-s4u repository to test against this new release
+ jed ~/Code/simgrid-template-s4u/.gitlab-ci.yml
+
+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/losely 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
+
+Doing a dot release:
+ - 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/highsierra to complete the build
+ - If it's not successful, fix it and push again
+ - Once it's successful on both appveyor and jenkins:
+ - Build the source tar.gz
+ - Build the jarfile
+ - Download the simgrid-doc-3.X.Y from the pages pipeline on framagit
+ - tag the release v3.X.Y and push the tag
+ - Merge 'master' into 'stable' and push it to framagit
+ - Do not merge into 'stable' before appveyor and jenkins are done,
+ or your jarfile will not contain the code you expect for win and
+ mac.
+ - Edit the tag on github and 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