1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125
|
/*!
@page inside_release Releasing SimGrid
@section inside_release_c Releasing the main library
@subsection inside_release_c_preconditions Before releasing
Please apply the following checklist before releasing.
- Sources
- 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.
- ChangeLog file
- All changes are documented
- The release date is indicated below 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
- Tests
- The "make distcheck" target works (tested by jenkins)
- All tests pass oneverything on ci + travis/macOS + AppVeyor
- 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).
@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 both appveyor and jenkins/highsierra 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
- This builds the tar.gz and jar artefacts. The old doc says how to do manually if something goes wrong.
- 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.
- Download the SimGrid-doc-3.X.Y (artefact of pipeline 'pages' on framagit)
Download the tgz and jar files (artefacts of the pipeline 'stable' on framagit)
- Push the archive files (tar.gz and jar) on gforge
- 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.
- Update the website
- emacs org/org-templates/level-0.org to change the release version, the tgz link and the jar link.
- make -C org all sync
- jed .gitlab-ci.yml
- Change the link to the SimGrid-doc-3_XX.zip file
- Only keep 2 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
- 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_publishing Publishing the release if it's a stable one (3.XX not 3.XX.Y)
- Announce the release
- Mail the simgrid-user mailing list
- the NEWS chunk in the mail;
- Hall of Fame in the mail
git shortlog -se v3.24..
- 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
- 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 once the docker is uploaded
jed ~/Code/simgrid-template-s4u/.gitlab-ci.yml
@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
- 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.
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
*/
|