X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/dc3c3416c4cca30fef7c29422d45094687f59893..7bb701664bbf4a34aa44336d1c6cfd93e2c94e5e:/doc/doxygen/inside_release.doc diff --git a/doc/doxygen/inside_release.doc b/doc/doxygen/inside_release.doc index 7da810f827..4874363335 100644 --- a/doc/doxygen/inside_release.doc +++ b/doc/doxygen/inside_release.doc @@ -1,110 +1,182 @@ /*! -\page inside_release SimGrid Developer Guide - Releasing +@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 + - 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) - - The URL provided to download in the examples of - doc/doxygen/install.doc is accurate. Note that updating the - version number is not enough as it only impacts the name that will - be given to the downloaded file. The real identifier is the number - before, between /s. This makes this part very difficult to - generate automatically. - Tests - All tests pass on a reasonable amount of platforms (typically, - everything on cdash) + 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 - - 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 -\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 -here. - -Then be sure having wget.exe in your path to get the online documentation. You can download it -here. - -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 +@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. + +@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 (tar.gz and jar) on gforge +- Post a news on gforge (before updating the website) +- 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 (that is the artefact of the pages job on framagit) files to the changelog. +- Update the .gitlab-ci.yml on the website + - Download the simgrid-doc from framagit and unpack it in position + - Only keep 2 versions so that people don't find older ones in google - 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 + 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 - 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-Java-${inside_release_version}.tar.gz' or -'SimGrid-Ruby-${inside_release_version}.tar.gz'. - -\verbatim -$ cd simgrid-java (or simgrid-ruby) -$ git reset --hard master -$ git clean -dfx -$ mkdir build -$ cd build -$ cmake .. -$ make dist -\endverbatim + - Hall of Fame in the mail@n + 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 +- Change the release number to 3.X.90 in CMakeLists.txt and sonar-project.properties docs/source/conf.py +- Deal with deprecations: + - Introduce the XBT_ATTRIB_DEPRECATED_v??? macro for the next release. + - 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 + +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 is a dot release of 3.X + - 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.90 is a git version, a preversion of 3.(X+1) (3.22.90 = pre-3.23) + - No expectations on such versions + +Doing a dot release: + - Update the version number in: + - CMakeLists.txt (in macros SIMGRID_VERSION_*) + - sonar-project.properties + - docs/source/conf.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: + - tag the release v3_X_Y and push the tag + - Merge 'master' into 'releases' and push it to framagit + - Do not merge into 'releases' before appveyor and jenkins are done, + or your jarfile will not contain the code you expect for win and + mac. */