FusionForge

Difference between revisions of "Release process"

From FusionForge Wiki
Jump to: navigation, search
(Clarify relationship with debian maintainers and reorder; fix typos; note TODO on method to create a proper tarball)
 
(41 intermediate revisions by 3 users not shown)
Line 1: Line 1:
Here's the current semi-formal way we make a release:
+
Here's the current semi-formal way we make a release:<br/>
 +
'''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.'''<br/>
 +
'''Disclaimer 2: sometime all steps are not mandatory.'''
 +
 
 +
= 6.x series =
 +
 
 +
Preparation:
 
* 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
 +
* 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>VERSION</tt> 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 <tt>debian/changelog</tt> 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 <tt>src/translations/fusionforge.pot</tt> with "<tt>make -C locale fusionforge.pot</tt>" 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 <tt>.po</tt> translations (<tt>rsync -Lrtvz  translationproject.org::tp/latest/fusionforge/ locale/</tt>, see [[Translations]]).
 +
* Tag the precise release point on the release branch (annotated with <tt>-a</tt> so that postcommitemail considers it) (and push the tag :)).
 +
* Create the archive (everything in <tt>~/src/</tt> directory, using <tt>make dist</tt>)
 +
* 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 [https://fusionforge.org/news/?group_id=6 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 <tt>rpm/fusionforge.spec.in:Release</tt>, <tt>:%changelog</tt> and <tt>:Source0</tt>
 +
# (see [https://fedoraproject.org/wiki/Packaging%3aNamingGuidelines#NonNumericRelease] 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 <tt>debian/changelog</tt> version as <tt>6.0.2+20150707-1</tt> (in the <tt>dch</tt> part)
 +
* Fedora:
 +
** Bump <tt>rpm/fusionforge.spec.in:Release</tt> and <tt>%changelog</tt>
 +
** Regen with <tt>./rpm/gen_spec.sh 6.0.2 20150707 </tt> (resulting in <tt>6.0.2-2.20150707</tt>, following existing <tt>6.0.2-1</tt>)
 +
 +
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 [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 <tt>src/CHANGES</tt> with 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 <tt>src/CHANGES</tt> with 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 <tt>src/www/index_std.php</tt> as well.
 
* Update <tt>src/www/index_std.php</tt> as well.
* Involve distro packagers (e.g. using Release Candidates) so they have a chance to give feedback if changes are necessary. For Debian, this is us :) - cf. project [https://fusionforge.org/projects/deb-packaging/ debian packaging].  No other distro right now :/
+
* Update <tt>src/common/include/FusionForge.class.php</tt> 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 <tt>src/translations/fusionforge.pot</tt> with <tt>src/utils/manage-translations.sh refresh</tt> and possibly send RCs to the translation coordinator (see [[Translations]])
 
* Make sure the current release point passes the [[Test Suite]].  
 
* Make sure the current release point passes the [[Test Suite]].  
 +
 +
The release itself:
 
* Decide the release at the next weekly meeting.
 
* Decide the release at the next weekly meeting.
* Update <tt>src/translations/fusionforge.pot</tt> (see [[Translations]]).
+
* Sync latest .po translations (see [[Translations]]).
* Tag the precise release point on the release branch.
+
* Tag the precise release point on the release branch (and push the tag :)).
* Create the archive (everything in ~/src/ directory) [TODO: clean-up methods? e.g. using git-archive?]
+
* Create the archive (everything in ~/src/ directory, using <tt>make buildtar</tt>)
 
* Add the archive at https://fusionforge.org/frs/?group_id=6.
 
* Add the archive at https://fusionforge.org/frs/?group_id=6.
 
* Make an official announcement on the fusionforge.org front page.
 
* Make an official announcement on the fusionforge.org front page.
Line 15: Line 104:
 
* Update all field values in the tracker (add new "Found in version" and "Target release" fields...).
 
* 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).
 
* 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.
 +
 +
=== Links ===
 +
 +
* [https://wiki.debian.org/BuildingFormalBackports#Self-contained_example_for_Apache_2.4 Instructions for building the Debian backports]

Latest revision as of 14:37, 15 October 2017

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.x 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.

Links