-
Notifications
You must be signed in to change notification settings - Fork 43
Release Actions
These actions are mandatory for every release (including minor ones), and are to be performed before the release is built.
Run VersionManager.py with the appropriate settings to update the version number.
If the version is a real release (not a release candidate), the CHANGELOG.md file must be updated, combining the beta and release candidate changes into a single section, and with it the debian/changelog file (this file has a very specific format, please be careful). If incompatible changes appeared, UPGRADE.md must be updated too.
Run the def_check.sh script and use the results to ensure that all the functions which the executable can write to a gtex file have been defined in the tex files. If a function in the gtex name space (\Gre...) can no longer be written by the executable, then it should be renamed to either the user (\gre...) or internal (\gre@...) name space or removed (whatever is appropriate).
Run the doc_check.sh script and use the results to check that all functions defined in the tex files are properly documented. Functions which are no longer defined in the tex files should have their documentation deleted. Also check that make doc in the doc/ directory will build the Reference Manual.
Once the above has been done and the version is correctly set in the repository, the commit representing the release must be tagged as vx.y.z:
git tag -a vx.y.z -m 'Releasing version x.y.z'
git push --tags
It may be a good idea to do the branch merging before tagging if you expect to have to resolve conflicts (this should be rare).
A release contains several components representing different platforms and distribution channels. In order to make sure each of these components is built correctly, you should first run make maintainer-clean, autoreconf, and ./configure on your repository and then build the components in the following order (do not clean the repository between steps):
The git repository doesn't contain genereted files (doc/GregorioRef.pdf, fonts/*.ttf) and contains specific development files useless to most users. Autotools provide a mechanism to build a source tarball that contains these generated files and only the files useful to the users, that's what we use to distribute Gregorio sources to end users.
To compile the source tarball:
make dist
and to check if everything went right:
make distcheck
it will create gregorio-x.y.z.tar.gz in the main directory. This is what gets uploaded to the release page on GitHub.
This step will also create the Reference Manual pdfs (GregorioRef.pdf and GregorioNabcRef.pdf) which should be uploaded to the release page on GitHub separately.
If the release will be uploaded to CTAN (the release is the one designated for that year's TeXLive release or is a bug fix thereunto which only effects the tex files), then run make ctan in the root directory of the repository to create the zip archive for uploading. This file does not get uploaded to the release page on GitHub, but to the CTAN archives using this page. If you have ctan-o-mat installed, you can also upload it using the ctan-upload.sh script. This script takes two arguments: the release announcement and the note for the CTAN and TeX Live maintainers.
Note: When uploading to CTAN, be sure to include a note for the CTAN and TeX Live maintainers if the release is for the TeX Live pretest and should not be added to the current year's version of TeX Live.
macOS packages can be built with 100% free software, but must be built on a Mac, so if no developper has access to a Mac, this step can be skipped (and help asked on the list). See the readme for details on the build. If they are built, then the Mac installer and uninstaller should be uploaded to the release page on GitHub.
The Windows installer can be built with 100% free softwares (Mingw, Wine, InnoSetup) on any flavor of Linux, and thus it seems fair to ask for all releases to contain it. See the readme for details on the build. Bugs found in the installer can lead to a new release. This installer should be renamed to indicate the version of Gregorio (gregorio-x_y_z-setup.exe) before it is uploaded to the release page on GitHub.
The last component to be built is the zip file containing the supplemental fonts. Run make supp-fonts-dist to generate it and upload it to the release page on GitHub.
The text in the release page must be set to the corresponding Changelog entries. If this is a final release (not a beta or release candidate) then use the consolidated Changelog entries and delete the notes and files for any beta or release candidate which corresponds the release being made.
The release must be announced on the gregorio users mailing list; the mail must include the relevant entries from CHANGELOG.md and UPGRADE.md and should include a link to the download page on GitHub.
Debian packages are a bit difficult to build, so they should be built by someone familiar with the process. The .deb file are built with the build-deb.sh script at the root of the repository. After that, they can be uploaded to the Gregorio PPA (ask a developer if you want to join the team).
It is also possible to build a version of any git commit using build-deb.sh --git (this auto-increments the changelog).