Difference between revisions of "Release process"
Beuc-inria (talk | contribs) (Use new debian/fixup_upload.sh) |
Beuc-inria (talk | contribs) (Note about spell-checking CHANGES) |
||
Line 8: | Line 8: | ||
* Announce intention to make a release on mailto:fusionforge-general@lists.fusionforge.org. | * Announce intention to make a release on mailto:fusionforge-general@lists.fusionforge.org. | ||
* Have a look at the current bugs [https://fusionforge.org/tracker/?atid=105&group_id=6&func=browse FF] [https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=fusionforge Deb] to see if important ones needs fixing | * Have a look at the current bugs [https://fusionforge.org/tracker/?atid=105&group_id=6&func=browse FF] [https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=fusionforge Deb] to see if important ones needs fixing | ||
− | * Update version in <tt>src/CHANGES</tt> and complete user-friendly description of what happened since the last release, e.g. [https://fusionforge.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=fusionforge/fusionforge.git;a=blob;f=src/CHANGES;hb=refs/heads/Branch_5_3]. Usually one would make a call to contributors so they update it, if not already. | + | * Update version in <tt>src/CHANGES</tt> and complete user-friendly description of what happened since the last release, e.g. [https://fusionforge.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=fusionforge/fusionforge.git;a=blob;f=src/CHANGES;hb=refs/heads/Branch_5_3]. Usually one would make a call to contributors so they update it, if not already. Spell-check it, too. |
* Update <tt>src/www/index_std.php</tt> as well. | * Update <tt>src/www/index_std.php</tt> as well. | ||
* Update <tt>VERSION</tt> to set the targeted version (e.g. 6.0rc4 or 6.0) | * Update <tt>VERSION</tt> to set the targeted version (e.g. 6.0rc4 or 6.0) |
Revision as of 11:15, 12 November 2015
Here's the current semi-formal way we make a release:
Disclaimer 1: this process is meant to be executed simultaneously by different people involved in the FusionForge community. We do not make a release alone in the dark. It's a common and shared process, when possible.
Disclaimer 2: sometime all steps are not mandatory.
6.0 series
Preparation:
- Announce intention to make a release on mailto:fusionforge-general@lists.fusionforge.org.
- Have a look at the current bugs FF Deb to see if important ones needs fixing
- Update version in src/CHANGES and complete user-friendly description of what happened since the last release, e.g. [1]. Usually one would make a call to contributors so they update it, if not already. Spell-check it, too.
- Update src/www/index_std.php as well.
- Update VERSION to set the targeted version (e.g. 6.0rc4 or 6.0)
- Involve distro packagers (e.g. using Release Candidates) so they have a chance to give feedback if changes are necessary. For Debian and Fedora, this is us :)
- Set debian/changelog to the correct version (e.g. 6.0~rc4-0 or 6.0-0, in UNRELEASED), so autoinstall/build.sh gets the correct version
- Update src/translations/fusionforge.pot with "make -C locale fusionforge.pot" and send RCs to the translation coordinator (see Translations)
- Make sure the current release point passes the Test Suite.
The release itself:
- Decide the release at the next weekly meeting.
- Sync latest .po translations (rsync -Lrtvz translationproject.org::tp/latest/fusionforge/ locale/, see Translations).
- Tag the precise release point on the release branch (annotated with -a so that postcommitemail considers it) (and push the tag :)).
- Create the archive (everything in ~/src/ directory, using make dist)
- Add the archive at https://fusionforge.org/frs/?group_id=6.
- If possible update fusionforge.org to the new version (showing we drink our own champagne).
- Notify TranslationProject coordinator of the new tarball (see Translations).
- Update all field values in the tracker (add new "Found in version" and "Target release" fields...).
- Push a new Debian version to unstable (and optionally to stable-backports).
- Roland notes: I run my "full-test.sh && pdebsign.sh && debrelease" routine :-) Builds the *.deb, runs the full testsuite in a VM, and if no error, then sign the packages and upload them.
Announcements and publicity:
- Write a news byte on fusionforge.org (and approve it for front page).
- Announce to fusionforge-general mailing-list.
- Also discussions@planetforge.org (as long as it's not actually closed, it might at least be used for something).
- Write about it on blogs (particularly syndicated blogs).
- Update version numbers and release dates in Wikipedia articles (at least fr, en and de).
- Update topic on IRC channel
- LinuxFR?
Debian release:
apt-get install devscripts fakeroot php5-cli tar xf fusionforge-X.X.X.tar.bz2 mv fusionforge-X.X.X.tar.bz2 fusionforge_X.X.X.orig.tar.bz2 cd fusionforge-X.X.X/ debian/fixup_upload.sh dch debuild cd ../ debsign *.changes -k XXXXXXXX dput *.changes cp fusionforge-X.X.X/debian/changelog .../fusionforge-git/src/debian/
Debian backport: use procedure from https://wiki.debian.org/BuildingFormalBackports#Self-contained_example_for_Apache_2.4 . Note: you can re-enable fusionforge-plugin-mediawiki.
Fedora release:
tar xf fusionforge-X.X.X.tar.bz2 cd fusionforge-X.X.X/ # check rpm/fusionforge.spec.in:Release, :%changelog and :Source0 # (see [2] for RCs) rpm/gen_spec.sh # Then see https://fedoraproject.org/wiki/Package_maintenance_guide#Typical_fedpkg_session # Sync fusionforge.spec with fusionforge-git/src/rpm/fusionforge.spec.in
Stable snapshots
Useful to push the stable branch to a distro without going through a full minor version release.
For a stable snapshot on July 7th, first:
make dist VERSION=6.0.2+20150707
Then make the release as described above, with the following variant:
- Debian: set debian/changelog version as 6.0.2+20150707-1 (in the dch part)
- Fedora:
- Bump rpm/fusionforge.spec.in:Release and %changelog
- Regen with ./rpm/gen_spec.sh 6.0.2 20150707 (resulting in 6.0.2-2.20150707, following existing 6.0.2-1)
You will usually start the changelog with New upstream snapshot following the stable branch.
Testsuite snapshots
This is fully automated, see DEB_Installation#Autobuilt_packages and RPM_Installation#Autobuilt_packages.
5.3 series
Preparation:
- Announce intention to make a release on mailto:fusionforge-general@lists.fusionforge.org.
- Have a look at the current bugs FF Deb to see if important ones needs fixing
- Update src/CHANGES with user-friendly description of what happened since the last release, e.g. [3]. Usually one would make a call to contributors so they update it, if not already.
- Update src/www/index_std.php as well.
- Update src/common/include/FusionForge.class.php to set the targeted version.
- Involve distro packagers (e.g. using Release Candidates) so they have a chance to give feedback if changes are necessary. For Debian and Fedora, this is us :)
- Update src/translations/fusionforge.pot with src/utils/manage-translations.sh refresh and possibly send RCs to the translation coordinator (see Translations)
- Make sure the current release point passes the Test Suite.
The release itself:
- Decide the release at the next weekly meeting.
- Sync latest .po translations (see Translations).
- Tag the precise release point on the release branch (and push the tag :)).
- Create the archive (everything in ~/src/ directory, using make buildtar)
- Add the archive at https://fusionforge.org/frs/?group_id=6.
- Make an official announcement on the fusionforge.org front page.
- If possible update fusionforge.org to the new version (showing we drink our own champagne).
- Notify TranslationProject coordinator of the new tarball (see Translations).
- Update all field values in the tracker (add new "Found in version" and "Target release" fields...).
- Push a new Debian version to unstable (and optionally to stable-backports).
- Roland notes: I run my "full-test.sh && pdebsign.sh && debrelease" routine :-) Builds the *.deb, runs the full testsuite in a VM, and if no error, then sign the packages and upload them.