Difference between revisions of "GNUstep release procedure"
| (8 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | Steps for releasing the GNUstep core libraries (as well as others): | |
| − | + | 1. Make sure news.texi and ReleaseNotes.gsdoc files are updated (or NEWS, ANNOUNCE, etc if it is a simple package). If the release is on a stable branch, also update these on the main branch so they are available to read in future releases. | |
| − | |||
| − | + | 2. Update the 'Version' file with the new version or make sure the top-level GNUmakefile has VERSION set if there is not a separate Version file. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | 3. core libraries: Update the documentation and release notes in the main directory: | |
| − | + | cd Documentation | |
| + | make clean; make; make regenerate | ||
| + | |||
| + | 4. Add a line in the ChangeLog, like: | ||
| + | |||
| + | '* Version 1.10.0' as well. | ||
| + | |||
| + | and commit the changed files. | ||
| + | |||
| + | 5. Tag the release | ||
| − | + | make git-tag | |
| + | git push --tags | ||
| − | + | 6. Make a source distribution | |
| − | + | make git-dist | |
| − | + | 7. Administrative stuff (Note: Admin-only scripts that I use to make this easier are in brackets): | |
| − | + | * Sign the packages. Use gpg --detach-sign package.tar.gz [gstep-sign] | |
| + | * Upload packages to ftp.gnustep.org, into the incoming directory [gstep-update]. | ||
| + | * Install the documentation and copy it to the web repository [update_documentation]. | ||
| + | * Update the index.html and resources/downloads.php pages with the news. | ||
| + | * Commit the web repository. | ||
| + | * Make an announcement on info-gnustep@gnu.org, etc | ||
| − | + | If the packages are used by the GNUstep umbrella package (runtime or development environment), then the umbrella package should be released too. | |
| − | + | == Preparation == | |
| − | + | It is desired that the release is made from git checkout. The release should correspond to a tagged state in the git. | |
| − | + | Also it is required that all release test passed. If not, the release should not be created. For more information about the tests see [[Quality assurance]]. | |
| − | + | Follow standard versioning guidelines. | |
| − | + | [[Category:Project procedures]] | |
Latest revision as of 08:06, 30 May 2024
Steps for releasing the GNUstep core libraries (as well as others):
1. Make sure news.texi and ReleaseNotes.gsdoc files are updated (or NEWS, ANNOUNCE, etc if it is a simple package). If the release is on a stable branch, also update these on the main branch so they are available to read in future releases.
2. Update the 'Version' file with the new version or make sure the top-level GNUmakefile has VERSION set if there is not a separate Version file.
3. core libraries: Update the documentation and release notes in the main directory:
cd Documentation make clean; make; make regenerate
4. Add a line in the ChangeLog, like:
'* Version 1.10.0' as well.
and commit the changed files.
5. Tag the release
make git-tag git push --tags
6. Make a source distribution
make git-dist
7. Administrative stuff (Note: Admin-only scripts that I use to make this easier are in brackets):
- Sign the packages. Use gpg --detach-sign package.tar.gz [gstep-sign]
- Upload packages to ftp.gnustep.org, into the incoming directory [gstep-update].
- Install the documentation and copy it to the web repository [update_documentation].
- Update the index.html and resources/downloads.php pages with the news.
- Commit the web repository.
- Make an announcement on info-gnustep@gnu.org, etc
If the packages are used by the GNUstep umbrella package (runtime or development environment), then the umbrella package should be released too.
Preparation
It is desired that the release is made from git checkout. The release should correspond to a tagged state in the git.
Also it is required that all release test passed. If not, the release should not be created. For more information about the tests see Quality assurance.
Follow standard versioning guidelines.