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.
14 - The version number is correctly marked in
15 - CMakeLists.txt (in macros SIMGRID_VERSION_*)
16 - sonar-project.properties
18 - The "make distcheck" target works (testing that every files needed
19 to build and install are included in the archive)
21 - All tests pass on a reasonable amount of platforms (typically,
22 everything on ci + travis/macOS + AppVeyor)
23 - You also tested to build and install the content of the source
24 archive on a reasonable amount of platforms (typically, 2 or 3).
26 - All changes are documented
27 - The release date is indicated below the changes
28 - The release is marked as stable above the changes (remove the UNRELEASED marker)
29 - The release dub name matches the one given in NEWS file
31 - The most notable changes of the version are documented
32 - The release date is indicated right below the version name
33 - The release dub name matches the one given in ChangeLog file
35 @subsection inside_release_c_source Building the source archive
37 This should be done from a clean git repository because some files are
38 included through globbing. The best is to use a clean checkout:
41 git clone --depth=1 ~/Code/simgrid
46 If you prefer, you can clean your repository the hard way:
48 git reset --hard master # remove all uncommited changes to the files tracked by git
49 git clean -dfx # delete all files and directories that are not tracked by git
53 @subsection inside_release_c_jarfile Building the binary jarfile
55 Get the jarfiles for several OSes on the CI slaves. Use Save under to
56 give a separate name to each of them.
58 - macOS, FreeBSD: on Jenkins
59 - Windows: on AppVeyor
60 - Linux: it is safer to rebuild them in a chroot (to avoid
61 boost-context and all other optional dependencies):
64 mkdir /tmp/build-amd64
65 cp SimGrid-3.*.tar.gz /tmp/build-amd64
66 sudo debootstrap --arch amd64 --variant=buildd testing /tmp/build-amd64 http://deb.debian.org/debian/
67 sudo chroot /tmp/build-amd64
68 echo "proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0" >> /tmp/fstab
69 mount proc /proc -t proc
70 apt-get install -y cmake default-jdk libboost-dev python3 doxygen
72 tar xfz ../SimGrid*tar.gz && cd SimGrid-*
73 cmake . -Denable_documentation=ON -Denable_java=ON
74 make -j4 && LC_ALL=C ctest -R java
77 Once all jarfiles are in a separate directory, run the following to
80 mkdir content ; cd content
82 for j in ../simgrid-linux64.jar ../simgrid*.jar ; do unzip -n $j ; done
83 # The content of all jar should be the same, but I prefer using the Linux64 version by default
84 # => unpack it first, and unpack the others with -n (never overwrite)
86 test -e doc/javadoc || echo "YOU ARE MISSING THE DOC"
88 du -sh . # 273M here. Let's strip (Darwin is already good)
89 strip NATIVE/*/*/*.so # Gets BSD and Linux versions, down to 116M
90 x86_64-linux-gnu-strip NATIVE/*/*/lib*dll # Gets Windows, down to 22M
93 zip -r ../simgrid-3_XX.jar * # Produced ../simgrid-3_XX.jar is 7.7M
96 To upload the file on gforge, you need to go to Files/Admin then clic
97 on the Settings icon near to the "Add a version" button, and then on
98 the settings icon of the release you want to change.
100 @subsection inside_release_c_postchecks Check list after releasing
102 - Tag the git repository (don't forget to push the tags to the main repo)
103 - Push the archive files (tar.gz and jar) on gforge
104 - Post a news on gforge (before updating the website)
105 - Document the tag on https://github.com/simgrid/simgrid/releases and
106 on https://framagit.org/simgrid/simgrid/tags
107 - Upload the files SimGrid-3.XX.tar.gz, simgrid-3_XX.jar and
108 SimGrid-doc-3_XX.zip (that is the artefact of the pages job on framagit) files to the changelog.
109 - Update the .gitlab-ci.yml on the website
110 - Download the simgrid-doc from framagit and unpack it in position
111 - Only keep 2 versions so that people don't find older ones in google
112 - Rebuild and resynchronize the website so that the file gets visible
113 from our download page.@n
114 - Edit org/org-templates/level-0.org to change the release version, the tgz link and the jar link.
115 - emacs org/site/index.org and C-c C-c the first source block to refresh the news; fake the date in the result.
116 - emacs org/site/download.org and C-c C-c the first source block to refresh the download.
117 - emacs org/site/documentation.org and edit the version links.
118 - make -C org all sync
120 - Change the link to the SimGrid-doc-3_XX.zip file
121 - Change the version number
122 - Change the link to latest
123 - git commit -a && git push
124 - Announce the release
125 - Mail the simgrid-user mailing list
126 - the NEWS chunk in the mail;
127 - Hall of Fame in the mail@n
128 git shortlog -se v3.21..
129 - Link to the ChangeLog on framagit (the version of that tag)
130 - Also mail some other lists (G5K users)
131 - Release the debian package
132 - rm -f ../simgrid_3.*+dfsg.orig.tar.xz
133 - uscan # download the new version
134 - gbp import-orig ../simgrid_3.*+dfsg.orig.tar.xz
135 - dch -i "New upstream release" # + copy the NEWS into debian/changelog
136 - git mv debian/libsimgrid3.XX.install debian/libsimgrid3.XY.install
137 - edit debian/control: s/simgrid3.XX/simgrid3.XY/
138 - Update the simgrid/package.py for spack: https://gitlab.inria.fr/solverstack/spack-repo
139 - Create the template for the next release in ChangeLog and NEWS files
140 Release Target date: https://en.wikipedia.org/wiki/Equinox
141 - Change the release number to 3.X.90 in CMakeLists.txt and sonar-project.properties docs/source/conf.py
142 - Deal with deprecations:
143 - Introduce the XBT_ATTRIB_DEPRECATED_v??? macro for the next release.
144 - Kill the one for the current release and remove all code that were
145 mandated by the deprecated functions (both in source and headers).
146 - Do the possible cleanups now that these features are gone.
147 - Update the Docker images (after pushing to the git)
148 - cd tools/docker && make stable tuto-s4u push
150 Release numbering semantic:
151 - 3.X is a named release.
152 - We have 4 named releases per year (for each equinox and solstice)
153 - The ChangeLog and NEWS are complete and informative
154 - All tests pass on all ci systems (or the workarounds are documented)
155 - We provide and store a source .tar.gz and a full jarfile on framagit
156 - Deprecated symbols remain usable for at least 3 named releases (~1 year)
157 - These releases are announced to the users
158 - 3.X.Y is a dot release of 3.X
159 - We provide and store a source .tar.gz and a full jarfile on framagit
160 - These releases are NOT announced publicly, nor really documented.
161 The idea is to have something close to a rolling release.
162 - External projects can depend on dot releases to loosen their
163 release process from ours, when 4 release a year is not enough
164 - 3.X.90 is a git version, a preversion of 3.(X+1) (3.22.90 = pre-3.23)
165 - No expectations on such versions
168 - Update the version number in:
169 - CMakeLists.txt (in macros SIMGRID_VERSION_*)
170 - sonar-project.properties
171 - docs/source/conf.py
172 - Commit and push to both framagit and github
173 - Wait for both appveyor and jenkins/highsierra to complete the build
174 - If it's not successful, fix it and push again
175 - Once it's successful:
176 - tag the release v3_X_Y and push the tag
177 - Merge 'master' into 'stable' and push it to framagit
178 - Do not merge into 'stable' before appveyor and jenkins are done,
179 or your jarfile will not contain the code you expect for win and