2 @page inside_release Releasing SimGrid
4 @section inside_release_c Releasing the main library
6 @subsection inside_release_c_preconditions Before releasing
8 Please apply the following checklist before releasing.
11 - The external patches (Debian, etc) are integrated.
12 The COPYING file is aligned with Debian's copyright file, and the
13 dates of SimGrid chunks are accurate.
15 - All changes are documented
16 - The release date is indicated below the changes
17 - The release is marked as stable above the changes (remove the UNRELEASED marker)
18 - The release dub name matches the one given in NEWS file
20 - The most notable changes of the version are documented
21 - The release date is indicated right below the version name
22 - The release dub name matches the one given in ChangeLog file
24 - The "make distcheck" target works (tested by jenkins)
25 - All tests pass oneverything on ci + travis/macOS + AppVeyor
26 - Tutorials and derivative projects build correctly
27 https://framagit.org/simgrid/simgrid-template-s4u/pipelines
28 https://framagit.org/simgrid/external-projects-ci/pipelines
29 - The python module builds (see below).
31 @subsection inside_release_c_releasing Actually releasing SimGrid
33 - Update the version number in:
34 - CMakeLists.txt (in macros SIMGRID_VERSION_*)
35 - sonar-project.properties
38 - Commit and push to both framagit and github
39 - Wait for both appveyor and jenkins/highsierra to complete the build
40 - If it's not successful, fix it and push again
41 - Once it's successful everywhere: merge 'master' into 'stable' and push it to framagit
42 - This builds the tar.gz and jar artefacts. The old doc says how to do manually if something goes wrong.
43 - Do not merge into 'stable' before appveyor and jenkins are done,
44 or your jarfile will not contain the code you expect for win and mac.
46 - Download the SimGrid-doc-3.X.Y (artefact of pipeline 'pages' on framagit)
47 Download the tgz and jar files (artefacts of the pipeline 'stable' on framagit)
48 - Push the archive files (tar.gz and jar) on gforge
49 - Tag the git repository v3.XX.X and push it to framagit and ghub
50 - Document the tag on framagit and ghub
51 - Upload the files SimGrid-3.XX.tar.gz, simgrid-3_XX.jar and SimGrid-doc-3_XX.zip
52 - Add a link to the version of the ChangeLog that comes with this tag.
54 - emacs org/org-templates/level-0.org to change the release version, the tgz link and the jar link.
55 - make -C org all sync
57 - Change the link to the SimGrid-doc-3_XX.zip file
58 - Only keep 2 versions so that people don't find older ones in google
59 - Change the link to latest
60 - git commit -a && git push # Check that the pipeline goes well on framagit
62 - Rebuild and upload the python package
63 - rm -rf dist/ ; python3 setup.py sdist # Build a source distrib
64 - test that the built distrib recompiles:
65 rm -rf /tmp/pysimgrid && mkdir /tmp/pysimgrid && cp dist/simgrid-*.tar.gz /tmp/pysimgrid
66 (cd /tmp/pysimgrid && tar xfz simgrid*.tar.gz && cd simgrid-*/ && python3 setup.py build)
67 - Upload it to pypi (WARNING: you cannot modify uploaded files, ever)
68 twine upload dist/simgrid-*.tar.gz
70 @subsection inside_release_c_publishing Publishing the release if it's a stable one (3.XX not 3.XX.Y)
72 - Announce the release
73 - Mail the simgrid-user mailing list
74 - the NEWS chunk in the mail;
75 - Hall of Fame in the mail
76 git shortlog -se v3.24..
77 - Link to the ChangeLog on framagit (the version of that tag)
78 - Also mail some other lists (G5K users)
79 - Release the debian package
80 - rm -f ../simgrid_3.*+dfsg.orig.tar.xz
81 - uscan # download the new version
82 - gbp import-orig ../simgrid_3.*+dfsg.orig.tar.xz
83 - dch -i "New upstream release" # + copy the NEWS into debian/changelog
84 - git mv debian/libsimgrid3.XX.install debian/libsimgrid3.XY.install
85 - edit debian/control: s/simgrid3.XX/simgrid3.XY/
86 - Update the simgrid/package.py for spack: https://gitlab.inria.fr/solverstack/spack-repo
87 - Update the Docker images (after pushing to the git)
88 - cd tools/docker && make stable tuto-s4u tuto-smpi push
89 - Update the simgrid-template-s4u repository to test against this new release once the docker is uploaded
90 jed ~/Code/simgrid-template-s4u/.gitlab-ci.yml
92 @subsection inside_release_c_postrelease Post-release cleanups
94 - Create the template for the next release in ChangeLog and NEWS files
95 Release Target date: https://en.wikipedia.org/wiki/Equinox
96 - Bump release number to 3.X.1 in CMakeLists.txt sonar-project.properties docs/source/conf.py setup.py
97 - Deal with deprecations:
98 - jed include/xbt/base.h: Introduce the next XBT_ATTRIB_DEPRECATED_v??? macro
99 - Kill the one for the current release and remove all code that were
100 mandated by the deprecated functions (both in source and headers).
101 - Do the possible cleanups now that these features are gone.
103 Release numbering semantic:
104 - 3.X is a named release.
105 - We have 4 named releases per year (for each equinox and solstice)
106 - The ChangeLog and NEWS are complete and informative
107 - All tests pass on all ci systems (or the workarounds are documented)
108 - We provide and store a source .tar.gz and a full jarfile on framagit
109 - Deprecated symbols remain usable for at least 3 named releases (~1 year)
110 - These releases are announced to the users
111 - 3.X.Y where Y is even: dot release of 3.X, prerelease of 3.(X+1)
112 - We provide and store a source .tar.gz and a full jarfile on framagit
113 - These releases are NOT announced publicly, nor really documented.
114 The idea is to have something close to a rolling release.
115 - External projects can depend on dot releases to loosen their
116 release process from ours, when 4 release a year is not enough
117 - 3.X.Y where Y is odd: git current status between two releases
118 - No expectations on such versions
120 - 3.22.4: unannounced/losely documented stable release
121 - 3.22.5: git status somewhere between the release of 3.22.4 and the next one
122 - 3.23: Documented and announced stable release