You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Improve building and releasing documentation and process
* Updates release documentation in developer docs
* Creates a new `GAMBIT_VERSION` file as the single place where version number needs to be updated.
* Organises build support files in a single directory with OS-specific subdirectories.
Closes#560
Copy file name to clipboardExpand all lines: doc/developer.contributing.rst
+57Lines changed: 57 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -160,3 +160,60 @@ To add a contributor, comment on a GitHub Issue or Pull Request, asking @all-con
160
160
@all-contributors please add @<username> for <contributions>
161
161
162
162
Refer to the `emoji key <https://allcontributors.org/docs/en/emoji-key>`__ for a list of contribution types.
163
+
164
+
Releases & maintenance branches
165
+
-------------------------------
166
+
167
+
Releases of Gambit are made by core developers.
168
+
Details of previous releases can be found in the `GitHub releases page <https://github.com/gambitproject/gambit/releases>`__.
169
+
170
+
Branches labeled ``maintX`` and ``maintX_Y``, where ``X`` is the major version number and ``Y`` is the minor version number, are associated with releases and point to the latest commit on a stable version.
171
+
Navigate to the Gambit repository on GitHub and select the `branches` tab to see the list of active maintenance branches.
172
+
Be sure to delete any maintenance branches that are no longer being maintained.
173
+
174
+
.. _making-a-new-release:
175
+
176
+
Making a new release
177
+
^^^^^^^^^^^^^^^^^^^^
178
+
179
+
When making a new release of Gambit, follow these steps:
180
+
181
+
1. Create a new branch from the latest commit on the ``master`` branch named ``maintX_Y``, where ``X`` is the major version number and ``Y`` is the minor version number of the new release.
182
+
183
+
2. Update the version number in the ``build_support/GAMBIT_VERSION`` file to ``X.Y.Z``.
184
+
185
+
All other files will automatically use the updated version number:
186
+
187
+
- `pyproject.toml` reads from GAMBIT_VERSION file at build time
188
+
- `configure.ac` reads from GAMBIT_VERSION file and substitutes into `build_support/osx/Info.plist` and `build_support/msw/gambit.wxs`
189
+
- `src/pygambit/__init__.py` reads from installed package metadata or GAMBIT_VERSION file
190
+
- `doc/conf.py` reads from GAMBIT_VERSION file at documentation build time
191
+
- Documentation pages reference the `|release|` substitution variable to automatically reflect the updated version number.
192
+
193
+
3. Update the `ChangeLog` file with a summary of changes
194
+
195
+
4. Once there are no further commits to be made for the release, create a tag for the release from the latest commit on the maintenance branch. ::
196
+
197
+
git tag -a vX.Y.Z -m "Gambit version X.Y.Z"
198
+
199
+
5. Push the maintenance branch and tags to the GitHub repository. ::
200
+
201
+
git push origin maintX_Y
202
+
git push origin --tags
203
+
204
+
6. Create a new release on the `GitHub releases page <https://github.com/gambitproject/gambit/releases>`__, using the tag created in step 4.
205
+
Include a summary of changes from the `ChangeLog` file in the release notes.
206
+
207
+
7. Currently there is no automated process for pushing the new release to PyPI. This must be done manually.
208
+
209
+
.. TODO: update this process to be automated via GitHub Actions: Issue #557
210
+
211
+
Patching maintained versions
212
+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
213
+
214
+
If you have bug fixes that should be applied across maintained versions:
215
+
216
+
1. Make a branch from the oldest maintenance branch to which the change applies
217
+
2. Apply the change and make a pull request to that maintenance branch
218
+
3. After the pull request is merged, open new pull requests to each subsequent maintenance branch and finally to the master branch, merging each in turn
219
+
4. Create new releases from each maintenance branch as needed, following the steps in :ref:`making-a-new-release`.
0 commit comments