Geeklog Release Procedures

From GeeklogWiki
Revision as of 14:24, 31 March 2013 by Tom (talk | contribs) (→‎Geeklog Sites)

Jump to: navigation, search

This page outlines the necessary steps to perform before, during, and after the release of a new Geeklog version.

Pre-Announcements

  • Obviously, plans for a new release should have been discussed on geeklog-devel. For security releases, the discussion may happen on geeklog-security only.
  • Notify the geeklog-translations mailing list to give translators a chance and a timeframe to update their translations.


The Tarball

  • Tagging a revision in the repository will trigger the automatic creation of a Geeklog tarball
  • The tarball will automatically show up in the submission queue of the File Management plugin on the Geeklog homepage
  • unpack tarball on the server
  • update site


Updating geeklog.net

  • TBD: document traps and pitfalls

The following files need special handling when updating geeklog.net:

  • remove the bundled lib-custom.php and robots.txt and use the copies already present on the webserver instead
  • check db-config.php and siteconfig.php for any required changes
  • lib-common.php: add the require_once line for the Bad Behavior plugin
  • header.thtml: check meta links, specifically the one to the favicon. In case of style sheet changes, update the ?v= parameter in the rel="stylesheet" link.
  • footer.thtml: make sure the version number is visible and add the "hosted by pair.com" link (as per our agreement with pair Networks).
  • style.css: add plugin-specific CSS, e.g. for the Forum plugin
  • The Download block on the top right uses a block header template without a title, so add this to the theme's functions.php: 
    $_BLOCK_TEMPLATE['download'] = 'blockheader-notitle-right.thtml,blockfooter.thtml';
    and make sure the blockheader-notitle-right.thtml template file exists.

Hacks

The following "Cool Hacks" are installed on geeklog.net:


Information to Update

Geeklog Sites

  • After approving the tarball from the File Management submission queue (the file can take up to xx to appear after adding the tag to the repository), go to the list of current versions. Edit all non-current versions and change their category from "Geeklog" to "Geeklog > old versions".
  • Publish an article on geeklog.net:
    • summarize the changes in this release
    • include a link to the entry in the download area
    • Convention for the story ID: geeklog-x.y.z, e.g. geeklog-1.5.2, geeklog-1.4.0sr6
    • Add story to the Geeklog topic and the Announcements topic (default). Make sure both are set to inherit
    • Announcements of new versions go into the Announcements topic. For security releases, either post the announcement in the Security topic, or post two articles (one in Announcements and the details of the security issues in Security).
    • don't forget to send pingbacks and ping weblog directories
  • Update the versionchecker.php script (not for betas/release candidates).
    • Once updated, the new version of the script should be added to the tools repository.
  • Send out an email to the geeklog-announce mailing list.
    • Provide a brief description of the release and link to the geeklog.net article for details.
  • Update the channel topic on #geeklog on irc.freenode.net
  • Update the wiki frontpage (not for betas/release candidates)
  • Update the bugtracker (not for betas/release candidates) to ensure the version is removed from the Roadmap and added in dropdowns available for bugreports:
    • Go to Manage -> Manage Projects -> Geeklog 1 -> Versions
    • Edit the version: Set the release date, check the "Released" checkbox
    • Additionally, post a news item on the bugtracker frontpage

External Sites

These sites should only be notified about final and security releases (i.e. not for betas and release candidates):

Retrieved from "http://wiki.geeklog.net/index.php?title=Geeklog_Release_Procedures&oldid=6264"