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
126
127
128
129
130
131
132
|
/*!
@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 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
- Release notes in the documentation
- The content of the future mail is part of the documentation, since
we won't send mails once gforge is definitly turned off.
- The date of the release is marked in the title
- Tests
- The "make distcheck" target works (tested by jenkins)
- All tests pass on everything on ci
- 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:
- ChangeLog header
- 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 jenkins/osX 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
- You can interrupt the build on jenkins, as it was tested just before
- This builds the tar.gz artefact.
- Download the simgrid-doc-4.X.Y (artefact of pipeline 'pages' on framagit)
Download the tgz file (artefact of the pipeline 'stable' on framagit)
- Tag the git repository v4.XX.X and push it to framagit and ghub
- Document the tag on framagit and ghub
- Upload the files simgrid-4.XX.tar.gz and simgrid-doc-4_XX.zip
- Add a link to the version of the ChangeLog that comes with this tag.
https://framagit.org/simgrid/simgrid/-/blob/v4.0/ChangeLog
- Update the website
- emacs org/org-templates/level-0.org to change the release version and the tgz link.
- jed .gitlab-ci.yml
- Change the link to the simgrid-doc-3_XX.zip file
- Only keep 2 old 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
- Download the simgrid-*.tar.gz artefact from a build-pip job on gitlab CI
- (alternatively, build it locally) rm -rf dist/ ; python3 -m build --outdir dist/
- Upload it to pypi (WARNING: you cannot modify uploaded files, ever)
twine upload dist/simgrid-*.tar.gz # User and token should be located in ~/.pypirc
@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 https://sympa.inria.fr/sympa/review/simgrid-community mailing list
- the NEWS chunk in the mail;
- Hall of Fame in the mail
git shortlog -se v3.29..
- 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_4.*.orig.tar.xz
- uscan # download the new version
- gbp import-orig ../simgrid_4.*.orig.tar.xz
- dch -i "New upstream release" # + copy the NEWS into debian/changelog
- git mv debian/libsimgrid4.XX.install debian/libsimgrid4.XY.install
- edit debian/libsimgrid4.XY.install and debian/control: s/simgrid3.XX/simgrid4.XY/
- Update the simgrid/package.py for spack: https://gitlab.inria.fr/solverstack/spack-repo
- Push the stable branch to github to rebuild and push the stable Docker images
- It downloads the latest tag on framagit, but sometimes gets out of synch.
Make sure that it's really the latest stable, as it sometimes rebuilds the previous release.
If this happens, just rerun the docker-stable action. Nothing should get hurt by the rebuild.
- Doing the same manually: cd tools/docker && make stable && make tuto-s4u tuto-smpi
(tuto-mc is not based on simgrid/stable but rebuilds from the git)
- Once the new images are built, trigger a rebuild of the simgrid-template-{s4u,smpi} repositories on framagit
- Add the new simgrid/stable image to the .gitlab-ci.yml of:
- https://framagit.org/simgrid/simgrid-template-s4u/
- https://framagit.org/simgrid/simgrid-template-smpi/
@subsection inside_release_c_postrelease Post-release cleanups
- Create the template for the next release in ChangeLog NEWS Release_Notes.rst files
Release Target date: https://en.wikipedia.org/wiki/Equinox
- Bump release number to 4.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
- jed docs/source/Doxyfile: ask doxygen to ignore the new 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.
- Regenerate the unstable docker with this new version
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 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 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/loosely 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
*/
|
