File: inside_release.doc

package info (click to toggle)
simgrid 3.25%2Bdfsg-5
  • links: PTS, VCS
  • area: main
  • in suites: bullseye
  • size: 23,308 kB
  • sloc: cpp: 100,922; ansic: 68,086; fortran: 6,061; xml: 5,176; f90: 5,123; java: 4,094; python: 2,623; perl: 1,843; sh: 1,241; makefile: 47; javascript: 7; sed: 6
file content (125 lines) | stat: -rw-r--r-- 6,143 bytes parent folder | download
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
    

*/